REST Code d'état HTTP si SUPPRIMER impossible
Ma question est assez générique sur le code de statut HTTP lorsqu'un SUPPRIMER est impossible sur la ressource (mais pas en ce qui concerne les droits de l'utilisateur).
Nous avons une API RESTful sur un type de ressource.
La méthode DELETE est autorisée sur la ressource, mais dans certaines conditions, une ressource ne peut pas être supprimée (s'il existe des données liées à cette ressource).
Quel est le code d'état HTTP correct à renvoyer au client dans cette situation?
Voici quelques-unes des possibilités que j'ai recueillies et pourquoi cela semble inapproprié dans mon cas:
- 4 ( Interdit ): Semble principalement lié aux droits de l'utilisateur.
- 405 ( Méthode non autorisée ): Il semble que l'API ne soit pas conçue pour répondre à cette méthode pour ce type de ressource.
- 409 ( Conflit ): Semble approprié mais le client devrait avoir la possibilité de résoudre le conflit avec l'API mais ce n'est pas le cas ici.
pdate: La liaison de données qui empêche la suppression de la ressource ne peut pas être modifiée via l'API REST. Cependant, la ressource peut être "libérée" par un autre moyen que la base de données d'où les données proviennent est également accessible par d'autres applications qui peuvent changer l'état d'une ressource (un SQL DELETE dans la base de données peut toujours le faire).
Je dirais que 409 est le plus approprié, étant donné son libellé dans le RFC:
Le code d'état 409 (Conflit) indique que la demande n'a pas pu être terminée en raison de n conflit avec l'état actuel de la ressource cible. Ce code est utilisé dans les situations où l'utilisateur pourrait être en mesure de résoudre le conflit et de soumettre à nouveau la demande. Le serveur DEVRAIT générer une charge utile qui comprend suffisamment d'informations pour qu'un utilisateur reconnaisse la source du conflit.
(c'est moi qui souligne)
D'après ma compréhension de la description de la question, la raison de la suppression de DELETE est exactement n conflit avec l'état actuel de la ressource cible. Comme indiqué dans le RFC, la charge utile de réponse peut donner une indication de la raison et, éventuellement, l'utilisateur pourrait être en mesure de le résoudre. Je ne vois rien dans la spécification qui rend 409 inapproprié simplement parce que l'API n'offre pas de possibilité de résolution de conflit.
UNE 409 Conflict la réponse est définitivement erronée si le client ne peut pas résoudre le conflit et supprimer la demande ultérieurement. Autrement dit, à moins que la ressource n'ait un suivi d'état, qu'elle puisse être supprimée ou non, 409 Conflict ne convient pas.
Un interdit 403 ne signifie pas nécessairement non autorisé:
Cependant, une demande peut être interdite pour des raisons sans rapport avec les informations d'identification.
- RFC 7231
L'implication est généralement là, cependant. Vous pouvez utiliser ce code, mais cela peut entraîner une certaine confusion. Ce sera particulièrement difficile si la méthode nécessite également une autorisation - vous aurez besoin d'un code ou de quelque chose dans la réponse indiquant si l'échec était lié à l'autorisation ou à la ressource non supprimable.
Je pense que 405 Method Not Allowed est la bonne façon de procéder.
Le code d'état 405 (méthode non autorisée) indique que la méthode reçue dans la ligne de demande est connue du serveur d'origine mais n'est pas prise en charge par la ressource cible.
- RFC 7231
La méthode DELETE n'est pas prise en charge pour cette ressource. Cela ressemble exactement à ce que vous décrivez. La spécification HTTP n'a pas vraiment de concept de type de ressource - juste une ressource. Il arrive que les gens regroupent les ressources individuelles sous le même point de terminaison pour raison, mais c'est juste une commodité pour les développeurs et les utilisateurs. En ce qui concerne la spécification HTTP, /widgets/12 et /widgets/15 et /widgets/3453 sont trois ressources différentes. Le fait que le même objet représente les trois de ces ressources sur le serveur est complètement hors de propos. Je pense que c'est le "type" auquel vous pensez, mais pour HTTP, ce n'est qu'un détail d'implémentation.