1035 votes

Code de réponse HTTP pour poste lorsque la ressource existe déjà

Je suis en train de construire un serveur qui permet aux clients de stocker des objets. Ces objets sont entièrement construits à côté client, complet avec Id d'objet qui sont permanent pour toute la durée de vie de l'objet.

J'ai défini l'API afin que les clients peuvent créer ou modifier des objets à l'aide de:

PUT /objects/{id} HTTP/1.1
...

{json representation of the object}

Le {id} est l'ID de l'objet, de sorte qu'il est une partie de l'URI de Demande.

Maintenant, je suis aussi en considérant permettant aux clients de créer l'objet à l'aide de POST:

POST /objects/ HTTP/1.1
...

{json representation of the object, including ID}

Car le POST est fait comme "annexer" fonctionnement, je ne suis pas sûr de quoi faire dans le cas où l'objet est déjà là. Dois-je traiter la demande comme une demande de modification ou dois-je retourner un code d'erreur (qui)?

1314voto

Wrikken Points 37727

Mon sentiment est - 409 Conflict est le plus approprié, cependant, que l'on voit rarement dans la nature de la formation:

La demande n'a pas pu être terminé en raison d'un conflit avec l'état actuel de la ressource. Ce code n'est autorisé que dans des situations où il est prévu que l'utilisateur peut être en mesure de résoudre le conflit et de soumettre à nouveau la demande. Le corps de la réponse DOIT inclure suffisamment d'informations pour permettre à l'utilisateur de reconnaître la source du conflit. Idéalement, l'entité de réponse serait suffisamment d'informations pour l'utilisateur ou de l'agent utilisateur pour résoudre le problème; toutefois, cela pourrait ne pas être possible et n'est pas nécessaire.

Les conflits sont les plus susceptibles de se produire en réponse à une demande. Par exemple, si la gestion des versions ont été utilisées et de l'entité à METTRE une modification d'une ressource qui sont en conflit avec ceux d'une précédente (tiers) de la demande, le serveur peut utiliser l'409 réponse pour indiquer qu'il ne peut pas remplir la demande. Dans ce cas, l'entité de réponse serait susceptible de contenir une liste des différences entre les deux versions dans un format défini par le Contenu de la réponse-Type.

109voto

Gareth Points 42402

Personnellement, je pars avec l’extension WebDAV``

11voto

Alfonso Tienda Points 335

Je ne pense pas que vous devriez faire ceci.

Le poste est, comme vous le savez, de modifier la collection, et il est utilisé pour créer un nouvel élément. Donc, si vous envoyez l’id (je pense que ce n’est pas une bonne idée), vous devez modifier la collection, par exemple, modifier l’ordre du jour, mais c’est déroutant.

Utilisez-la pour ajouter un élément, sans id. C’est la meilleure pratique.

8voto

alanjds Points 402

"302 Found" semble logique pour moi. Et la RFC 2616 dit qu'il PEUT répondre à d'autres demandes que d'OBTENIR et de la TÊTE (et ce sûrement comprend POST)

Mais il garde toujours le visiteur d'aller à cette URL pour obtenir ce "Trouvé" des ressources, par la RFC. Pour se rendre à aller directement vers le réel "Trouvé" de l'URL, on devrait être à l'aide de "303 Voir d'Autres", qui fait sens, mais les forces d'un autre appel pour OBTENIR son adresse URL suivante. Sur le bon côté, cela s'est mis en cache.

Je pense que je voudrais utiliser "303 Voir d'Autres". Je ne sais pas si je peux répondre avec la "chose" qui se trouve dans le corps, mais je voudrais le faire pour sauver un aller-retour vers le serveur.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X