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

842

Je construis un serveur qui permet aux clients de stocker des objets. Ces objets sont entièrement construits côté client, avec des ID d'objet qui sont permanents pour toute la durée de vie de l'objet.

J'ai défini l'API pour que les clients puissent créer ou modifier des objets en utilisant PUT:

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

{json representation of the object}

Le {id} est l'ID d'objet, il fait donc partie de l'URI de demande.

Maintenant, j'envisage également d'autoriser les clients à créer l'objet à l'aide de POST:

POST /objects/ HTTP/1.1
...

{json representation of the object, including ID}

Étant donné que POST est conçu comme une opération "ajouter", je ne sais pas quoi faire au cas où l'objet est déjà là. Dois-je traiter la demande comme une demande de modification ou dois-je renvoyer un code d'erreur (lequel)?

rest http http-status-codes

— vmj
source

5

En juin 2016, FB en fixait manifestement 200 lors de l'inscription lorsque le courrier électronique existait

— Vert

4

L'API Github renvoie 422 lors de la tentative de création d'une ressource (équipe / dépôt) avec un nom déjà utilisé

— Ken

1

Cela dépend si vous considérez l'existence de l'objet comme une erreur ou non. Si vous traitez l'ajout, 200 ou 204 sont les codes de réponse les plus appropriés.

— Suncat2000

1059

Mon sentiment est 409 Conflictle plus approprié, cependant, rarement vu dans la nature bien sûr:

La demande n'a pas pu être traitée en raison d'un conflit avec l'état actuel de la ressource. Ce code n'est autorisé que dans les situations où l'on s'attend à ce que l'utilisateur puisse résoudre le conflit et soumettre à nouveau la demande. Le corps de réponse DEVRAIT inclure suffisamment d'informations pour que l'utilisateur reconnaisse la source du conflit. Idéalement, l'entité de réponse comprendrait suffisamment d'informations pour que l'utilisateur ou l'agent utilisateur puisse résoudre le problème; cependant, cela pourrait ne pas être possible et n'est pas requis.

Les conflits sont plus susceptibles de se produire en réponse à une demande PUT. Par exemple, si le contrôle de version était utilisé et que l'entité PUT incluait des modifications apportées à une ressource qui entrent en conflit avec celles apportées par une demande antérieure (tierce), le serveur peut utiliser la réponse 409 pour indiquer qu'il ne peut pas terminer la demande. . Dans ce cas, l'entité de réponse contiendrait probablement une liste des différences entre les deux versions dans un format défini par le type de contenu de la réponse.

— Wrikken
source

11

pourquoi ne pas opter pour 400 Bad Request? Pour moi, cela ressemble un peu à une erreur de validation (vous fournissez une charge utile incorrecte avec un identifiant illégal).

— manuel aldana

314

400 => "La requête n'a pas pu être comprise par le serveur en raison d'une syntaxe mal formée" . Et le serveur comprend parfaitement, mais n'est pas en mesure de se conformer en raison d'un conflit. Il n'y a rien de mal avec la requête et la syntaxe, seulement un problème de données. Un 400 me ferait instantanément croire que l'ensemble du mécanisme que j'utilise est défectueux, au lieu de simplement les données.

— Wrikken

42

@Wrikken Ce n'est plus correct. HTTP 400 a été modifié dans la RFC 7231 pour signifier "le serveur ne peut pas ou ne traitera pas la demande en raison de quelque chose qui est perçu comme une erreur client (par exemple, une syntaxe de demande incorrecte, un cadrage de message de demande invalide ou un routage de demande trompeur)." Je ne dis pas que 400 est une utilisation correcte dans ce cas, mais cela pourrait être correct avec la nouvelle définition de 400.

— javajavajavajavajava

19

@javajavajavajavajava: malgré tout, les données en double ne sont pas une «erreur client» dans mon esprit, mais c'est dans l'œil du spectateur bien sûr.

— Wrikken

21

Je reviens HTTP 409avec un en- Locationtête pointant vers la ressource existante / conflictuelle.

— Gili

100

Selon la RFC 7231 , un 303 See Other PEUT être utilisé si le résultat du traitement d'un POST serait équivalent à une représentation d'une ressource existante .

— Nullius
source

4

À mon avis, cela pourrait bien être la réponse acceptée. Bien que "MAI" indique un élément complètement facultatif, il s'agit du seul code de réponse suggéré par la documentation officielle RFC 7231 .

— Nando

16

C'est la réponse la plus reposante.

— Seth

6

Je pense que le contexte est important. Par exemple: retourner un 303 implique une redirection vers la ressource trouvée est nécessaire. Cela pourrait avoir un sens dans un appel de serveur à serveur, mais si vous exécutiez un processus d'enregistrement d'utilisateur, cela n'aurait aucun sens.

— Sinaesthetic du

11

Désolé, je vote en bas. Les HTTP 300 concernent la redirection, et la redirection vers un autre objet qui a probablement des propriétés différentes serait très trompeuse.

— Michael Scheper

6

Vous n'avez pas à être désolé. Cependant, si la représentation est équivalente à une ressource existante, comment peut-elle avoir des propriétés différentes? Et même si c'était le cas, comment une redirection serait-elle trompeuse? L'OP dit: Je ne sais pas quoi faire au cas où l'objet serait déjà là. Il s'agit en fait du «même» objet. Pourquoi une redirection serait-elle trompeuse? Vous parlez d' un autre objet qui, dans l'esprit du PO, ne l'est clairement pas.

— Nullius

86

Personnellement, je vais avec l'extension WebDAV 422 Unprocessable Entity.

Selon RFC 4918

Le 422 Unprocessable Entitycode d'état signifie que le serveur comprend le type de contenu de l'entité de demande (donc un 415 Unsupported Media Typecode d'état est inapproprié), et la syntaxe de l'entité de demande est correcte (donc un 400 Bad Requestcode d'état est inapproprié) mais n'a pas pu traiter les instructions contenues.

— Gareth
source

19

C'est une pensée intéressante et m'a incité à lire enfin le RFC WebDAV. Cependant, je pense que la signification de 422 est que la demande et l'entité incluse étaient syntaxiquement correctes mais sémantiquement n'avaient pas de sens.

— vmj

4

JSON mal formé n'est pas une entité syntaxiquement correcte, donc un 422me semble étrange ...

— awendt

7

Je n'irais pas avec ça. À partir de la même URL référencée dans la réponse: "Par exemple, cette condition d'erreur peut se produire si un corps de requête XML contient des instructions XML bien formées (c'est-à-dire syntaxiquement correctes) mais sémantiquement erronées." C'est la vraie signification d'une entité non traitable, contrairement au cas où vous envoyez une entité de demande complètement valide avec une syntaxe ET une sémantique valides, mais le seul problème est qu'elle entre en conflit avec une entité existante. En fait, si la sémantique de l'entité de demande n'était pas valide, il ne devrait pas du tout exister une entité similaire.

— Tamer Shlash

1

Ajout au commentaire Tamer, si la deuxième demande venait en premier, alors elle réussirait, ce qui ne sera pas possible si c'était sémantiquement correct. Par conséquent, dans une sémantique correcte, cela ne s'appliquerait pas ici.

— Harish

4

@Tamer Pourquoi? La commande "Veuillez créer l'objet xy" est syntaxiquement correcte. Il n'est sémantiquement correct que s'il est possible de créer l'objet xy. Si l'objet xy existe déjà, il ne peut plus être créé, il s'agit donc d'une erreur sémantique.

— Hagen von Eitzen

48

Tout dépend du contexte , et aussi de qui est responsable du traitement des doublons dans les demandes (serveur ou client ou les deux)

Si le serveur pointe simplement le doublon , regardez 4xx:

400 Bad Request - lorsque le serveur ne traitera pas une demande car c'est une faute évidente du client
409 Conflit - si le serveur ne traitera pas une demande, mais que la raison n'est pas la faute du client
...

Pour la gestion implicite des doublons, regardez 2XX:

200 OK
201 créé
...

si le serveur doit renvoyer quelque chose , regardez 3XX:

302 trouvés
303 Voir les autres
...

lorsque le serveur est capable de pointer la ressource existante, cela implique une redirection.

Si ce qui précède ne suffit pas, il est toujours recommandé de préparer un message d'erreur dans le corps de la réponse.

— Sławomir Lenart
source

2

La demande ne duplique pas une ressource, elle ajoute des données à une seule. À mon avis, la vôtre est la meilleure réponse de toutes.

— Suncat2000

28

Tard dans le jeu peut-être mais je suis tombé sur ce problème sémantique en essayant de créer une API REST.

Pour développer un peu la réponse de Wrikken, je pense que vous pouvez utiliser soit 409 Conflictou 403 Forbiddenselon la situation - en bref, utiliser une erreur 403 lorsque l'utilisateur ne peut absolument rien faire pour résoudre le conflit et terminer la demande (par exemple, il ne peut pas envoyer de DELETEdemande de suppression explicite de la ressource), ou utilisez 409 si quelque chose peut être fait.

10.4.4 403 Interdit

Le serveur a compris la demande, mais refuse de la satisfaire. L'autorisation n'aidera pas et la demande NE DEVRAIT PAS être répétée. Si la méthode de demande n'était pas HEAD et que le serveur souhaite rendre public pourquoi la demande n'a pas été satisfaite, il DEVRAIT décrire la raison du refus dans l'entité. Si le serveur ne souhaite pas mettre ces informations à la disposition du client, le code d'état 404 (Not Found) peut être utilisé à la place.

De nos jours, quelqu'un dit "403" et un problème d'autorisations ou d'authentification vient à l'esprit, mais la spécification dit que c'est essentiellement le serveur qui dit au client qu'il ne va pas le faire, ne le demandez plus, et voici pourquoi le client ne devrait pas 't.

Pour ce qui est de PUT vs POST... POSTdoit être utilisé pour créer une nouvelle instance d'une ressource lorsque l'utilisateur n'a aucun moyen de créer ou ne doit pas créer un identifiant pour la ressource. PUTest utilisé lorsque l'identité de la ressource est connue.

9.6 PUT

...

La différence fondamentale entre les requêtes POST et PUT se reflète dans la signification différente de l'URI de demande. L'URI dans une demande POST identifie la ressource qui gérera l'entité incluse. Cette ressource peut être un processus d'acceptation de données, une passerelle vers un autre protocole ou une entité distincte qui accepte les annotations. En revanche, l'URI dans une demande PUT identifie l'entité jointe à la demande - l'agent utilisateur sait quel URI est prévu et le serveur NE DOIT PAS tenter d'appliquer la demande à une autre ressource. Si le serveur souhaite que la demande soit appliquée à un URI différent,

il DOIT envoyer une réponse 301 (déplacée en permanence); l'agent utilisateur PEUT alors prendre sa propre décision concernant la redirection ou non de la demande.

— p0lar_bear
source

7

Je pense que 403 Forbidden implique que, même si l'utilisateur est authentifié , il n'est pas autorisé à exécuter l'action demandée. Je ne l'utiliserais pas pour des erreurs de validation. Exemple : Non connecté, j'essaie de supprimer quelque chose. Le serveur m'envoie 401 non autorisé (qui est juste mal nommé, devrait être 401 non authentifié ). Je me connecte et réessaye. Cette fois, le serveur vérifie mes autorisations, constate que je ne suis pas autorisé et renvoie 403 Interdit . Voir aussi cette question .

— Stijn de Witt

Hm ... c'est vrai. L'idée ici était de dire à l'utilisateur que ses autorisations rendaient la ressource immuable dans le cas d'utilisation de l'OP - elle existe déjà, vous n'avez aucune autorisation de faire quoi que ce soit pour résoudre le conflit, n'essayez pas de recréer la ressource.

— p0lar_bear

3

Selon la spécification, il est sous-entendu que l'erreur 409 ne peut pas être renvoyée par une POSTdemande (lorsqu'elle est utilisée correctement), car elle indique qu'elle doit être renvoyée en cas de conflit avec la ressource cible . Étant donné que la ressource cible n'a pas encore été publiée, elle ne peut pas être en conflit, et donc répondre avec 409 Conflictn'a aucun sens.

— Grant Gryczan

1

Je ne déduirais pas qu'une erreur 409 ne peut pas être retournée par un POST, en fait, je déduirais le contraire parce que "les conflits sont plus susceptibles de se produire en réponse à une demande PUT." semble indiquer que d'autres méthodes de demande peuvent également utiliser ce code. De plus, «le corps de la réponse doit inclure suffisamment d'informations pour que l'utilisateur reconnaisse la source du conflit. Idéalement, l'entité de réponse devrait inclure suffisamment d'informations pour que l'utilisateur ou l'agent utilisateur puisse résoudre le problème; cependant, cela pourrait ne pas être possible et est pas nécessaire . " ( webdav.org/specs/rfc2616.html#status.409 )

— JWAspin

14

"302 Found" me semble logique. Et le RFC 2616 dit qu'il peut être répondu pour d'autres demandes que GET et HEAD (et cela inclut sûrement POST)

Mais cela permet toujours au visiteur d'accéder à cette URL pour obtenir cette ressource "Trouvé", par le RFC. Pour qu'il aille directement à l'URL réelle "trouvée", il faut utiliser "303 See Other", ce qui est logique, mais force un autre appel à GET son URL suivante. Du bon côté, ce GET est cacheable.

Je pense que j'utiliserais "303 See Other" . Je ne sais pas si je peux répondre avec la "chose" trouvée dans le corps, mais je voudrais le faire pour enregistrer un aller-retour sur le serveur.

MISE À JOUR: Après avoir relu la RFC, je pense toujours qu'un code "4XX + 303 trouvé" inexistant devrait être le bon. Cependant, le «conflit 409» est le meilleur code de réponse existant (comme indiqué par @Wrikken), peut-être comprenant un en-tête Location pointant vers la ressource existante.

— alanjds
source

88

Les états 3xx sont destinés à la redirection

— Aviram Netanel

1

"La ressource demandée réside temporairement sous un URI différent." de w3.org/Protocols/rfc2616/rfc2616-sec10.html

— statueofmike

1

À mon humble avis, "307 Redirection temporaire" est la véritable redirection temporaire. "302" est ambigu, mais "TROUVE !!" est le message vraiment souhaité ici. Le meilleur compromis sans ambiguïté est «303 See Other» sur la sémantique HTTP. J'irais avec "303 See Other".

— alanjds

@DavidVartanian Hum ... Je ne vois pas d'erreur ici. Le client envoie une bonne demande, mais comment dire "Désolé, mais ce que vous essayez de créer ici existe déjà"? Semble un travail pour certains 3xx. Ce n'est pas un 4xx pour moi, car il n'y a pas d'erreur client.

— alanjds

1

@DavidVartanian Merci pour la discussion. Mise à jour de la réponse vers 409 . Le client a tort de demander des choses impossibles, même s'il ne sait pas que c'est impossible.

— alanjds

11

Je ne pense pas que tu devrais faire ça.

Le POST est, comme vous le savez, pour modifier la collection et il est utilisé pour CRÉER un nouvel élément. Donc, si vous envoyez l'identifiant (je pense que ce n'est pas une bonne idée), vous devez modifier la collection, c'est-à-dire modifier l'élément, mais c'est déroutant.

Utilisez-le pour ajouter un élément, sans identifiant. C'est la meilleure pratique.

Si vous souhaitez capturer une contrainte UNIQUE (pas l'id), vous pouvez répondre 409, comme vous pouvez le faire dans les requêtes PUT. Mais pas l'ID.

— Alfonso Tienda
source

Qu'en est-il d'un objet qui a une relation de table de jointure? Supposons que nous ayons un compte, un produit et un compte_produit comme tables de base de données. Je veux ajouter un produit à un compte, je voudrais donc publier dans / account / {id} / product avec le product_id. Si une seule relation compte-produit est autorisée, que dois-je retourner?

— partkyle

2

Oubliez les tables de base de données. Disons qu'un produit ne peut être lié qu'à un compte ... Alors c'est une relation un à plusieurs. Donc, POST / product / {id} avec {'account': account_id}. Si la cardinalité maximale est définie sur '1' (relation un à un) .... Pourquoi sont-ils des objets de repos séparés? Une erreur de cardinalité ne sera qu'une erreur de 400. Rester simple. J'espère avoir compris votre question.

— Alfonso Tienda du

Je viens de poser cette question aussi et pour moi l'ID n'est pas l'ID technique sur la base de données mais quelque chose comme le code de l'entreprise. Dans cette application, un utilisateur gestionnaire peut créer des entreprises et doit leur donner un code. Il s'agit de l'ID d'entreprise de l'utilisateur, bien que la table DB ait également un ID technique. Donc, dans mon cas, je retournerai un 409 si le même code d'entreprise existe déjà.

— AlexCode

@partkyle Cesser d'utiliser les PK comme identifiants publics !!

— Sinaesthetic

Certaines entités ont des contraintes uniques sur elles, pas seulement l'id. Comme un compte, vous ne pouvez pas créer de compte si l'utilisateur ne fournit pas de nom d'utilisateur. Et ajouter un compte sans nom d'utilisateur est évidemment impossible

— rocketspacer

9

J'irais avec 422 Unprocessable Entity, qui est utilisé lorsqu'une demande n'est pas valide mais que le problème n'est pas lié à la syntaxe ou à l'authentification.

Comme argument contre d'autres réponses, utiliser n'importe quel 4xxcode non- erreur impliquerait que ce n'est pas une erreur client, et c'est évidemment le cas. Utiliser un 4xxcode sans erreur pour représenter une erreur client n'a tout simplement aucun sens.

Il semble que ce 409 Conflictsoit la réponse la plus courante ici, mais, selon la spécification, cela implique que la ressource existe déjà et que les nouvelles données que vous lui appliquez sont incompatibles avec son état actuel. Si vous envoyez unPOSTdemande, avec, par exemple, un nom d'utilisateur déjà pris, il n'est pas réellement en conflit avec la ressource cible, car la ressource cible (la ressource que vous essayez de créer) n'a pas encore été publiée. Il s'agit d'une erreur spécifique au contrôle de version, en cas de conflit entre la version de la ressource stockée et la version de la ressource demandée. C'est très utile à cet effet, par exemple lorsque le client a mis en cache une ancienne version de la ressource et envoie une demande basée sur cette version incorrecte qui ne serait plus conditionnellement valide. "Dans ce cas, la représentation de la réponse contiendrait probablement des informations utiles pour fusionner les différences en fonction de l'historique des révisions." La demande de création d'un autre utilisateur avec ce nom d'utilisateur n'est tout simplement pas traitable, n'ayant rien à voir avec le contrôle de version.

Pour mémoire, 422 est également le code d'état que GitHub utilise lorsque vous essayez de créer un référentiel avec un nom déjà utilisé.

— Grant Gryczan
source

422 est une spécification webdav, donc je ne conseillerais pas de l'utiliser pour une API REST

— rwenz3l

7

Je pense que pour REST, il suffit de prendre une décision sur le comportement de ce système particulier, auquel cas, je pense que la "bonne" réponse serait l'une des quelques réponses données ici. Si vous voulez que la demande s'arrête et se comporte comme si le client avait fait une erreur qu'il devait corriger avant de continuer, utilisez 409. Si le conflit n'est vraiment pas si important et que vous souhaitez continuer la demande, répondez en redirigeant le client à l'entité trouvée. Je pense que les API REST appropriées devraient rediriger (ou au moins fournir l'en-tête d'emplacement) vers le point de terminaison GET pour cette ressource après un POST de toute façon, donc ce comportement donnerait une expérience cohérente.

EDIT: Il convient également de noter que vous devriez envisager un PUT puisque vous fournissez l'ID. Ensuite, le comportement est simple: "Je me fiche de ce qu'il y a en ce moment, mettez cette chose là." Autrement dit, s'il n'y a rien, il sera créé; si quelque chose est là, il sera remplacé. Je pense qu'un POST est plus approprié lorsque le serveur gère cet ID. Séparer les deux concepts vous indique essentiellement comment y faire face (c'est-à-dire que PUT est idempotent donc il devrait toujours fonctionner aussi longtemps que la charge utile est validée, POST crée toujours, donc s'il y a une collision d'ID, alors un 409 décrirait ce conflit) .

— Sinaesthetic
source

Selon la spécification, il est implicite que l'erreur 409 ne peut pas être renvoyée par une POSTdemande (lorsqu'elle est utilisée correctement), car elle indique qu'elle doit être renvoyée en cas de conflit avec la ressource cible . Étant donné que la ressource cible n'a pas encore été publiée, elle ne peut pas être en conflit, et donc répondre avec 409 Conflictn'a aucun sens.

— Grant Gryczan

Imo discutable. Si vous publiez dans / utilisateurs, la ressource est la collection au lieu de l'enregistrement individuel / utilisateurs / {id}

— Sinaesthetic

Il s'agit d'une erreur spécifique au contrôle de version, en cas de conflit entre la version de la ressource stockée et la version de la ressource demandée. C'est très utile à cet effet, par exemple lorsque le client a mis en cache une ancienne version de la ressource et envoie une demande basée sur cette version incorrecte qui ne serait plus conditionnellement valide. "Dans ce cas, la représentation de la réponse contiendrait probablement des informations utiles pour fusionner les différences en fonction de l'historique des révisions."

— Grant Gryczan

J'aime bien votre suggestion PUT.

— Grant Gryczan

4

Un autre traitement potentiel consiste à utiliser PATCH après tout. Un PATCH est défini comme quelque chose qui change l'état interne et n'est pas limité à l'ajout.

PATCH résoudrait le problème en vous permettant de mettre à jour des éléments déjà existants. Voir: RFC 5789: PATCH

— Martin Kersten
source

2

Le patch est comme PUT mais pas un remplacement complet. Il est utilisé pour modifier un morceau de la ressource comme l'ajout, la suppression ou la modification d'un seul élément de la ressource au lieu de le remplacer dans son ensemble.

— Sinaesthetic

3

Pourquoi pas un 202 accepté ? C'est une demande OK (200s), il n'y a pas eu d'erreurs client (400s) en soi.

De 10 définitions de code d'état :

"202 Accepté. La demande a été acceptée pour traitement, mais le traitement n'est pas terminé."

... parce qu'il n'avait pas besoin d'être terminé, car il existait déjà. Le client ne sait pas qu'il existait déjà, il n'a rien fait de mal.

Je me penche sur le lancement d'un 202 et le retour d'un contenu similaire à ce qu'un GET /{resource}/{id}aurait retourné.

— Phillip Harrington
source

21

Cette réponse est fausse. 202 signifie que le serveur n'a pas trouvé de problème avec la demande, mais a choisi de traiter la demande après avoir répondu. Cela signifie également qu'il s'attend à ce que le traitement réussisse. Dans notre cas, le serveur sait que le traitement échouera, donc 202 est la mauvaise réponse.

— Adrian

4

Un exemple de 202 serait une file d'attente ou un abonnement. En d'autres termes, le résultat de la demande peut ne pas être disponible immédiatement si vous l'interrogez en ce moment.

— Sinaesthetic

1

Cela serait approprié si le serveur traitait toujours la demande. 200 ou 204 seraient plus courants. Étant donné que l'OP effectue une demande d'ajout, l'existence de l'objet est une condition attendue et non une erreur.

— Suncat2000

Cela n'a aucun sens de dire au client que la demande a été acceptée car vous savez déjà qu'elle ne l'a pas été!

— lucastamoios

1

@Adrian et lucastamoios je pense que vous supposez tous deux que le serveur lit de manière synchrone dans la base de données, avant de fournir la réponse. Ce n'est pas toujours le cas, donc cette réponse n'est pas "fausse", car le serveur ne "connaît" pas toujours l'enregistrement existant. C'est très bien le cas dans les systèmes asynchrones où la couche api enregistre simplement les demandes de traitement par les travailleurs en arrière-plan.

— gsaslis

2

Je suis tombé sur cette question tout en vérifiant le code correct pour l'enregistrement en double.

Excusez mon ignorance mais je ne comprends pas pourquoi tout le monde ignore le code "300" qui dit clairement "choix multiple" ou "ambigu"

À mon avis, ce serait le code parfait pour construire un système non standard ou particulier pour votre propre usage. Je peux me tromper aussi!

https://tools.ietf.org/html/rfc7231#section-6.4.1

— Hitin
source

Ma compréhension: "le code d'état indique que la ressource cible a plus d'une représentation ... des informations sur les alternatives sont fournies afin que l'utilisateur (ou l'agent utilisateur) puisse sélectionner une représentation préférée en redirigeant sa demande vers une ou plusieurs d'entre elles identifiers "Nous essayons explicitement d'empêcher plus d'une représentation. Il n'y a pas d'options. Le client n'a pas d'autre choix. Le client doit soumettre à nouveau avec un identifiant différent. Cela dit, il convient également de déterminer si des identifiants uniques doivent être générés dans le client par rapport au serveur.

— musicin3d

Sémantiquement, le client dit "Créer ceci" et le serveur répond en disant "Allez ici à la place". La conversation n'a aucun sens. C'est presque comme si le serveur demandait au client de "publier à cet endroit à la place". Les 300 sont une réponse plus appropriée à une demande GET ou à un POST dans le cas où le serveur répond "Ok, je l'ai créé et c'est ici" ..

— Sinaesthetic

2

Il est plus probable 400 Bad Request

6.5.1. 400 Mauvaise demande

Le code d'état 400 (Bad Request) indique que le serveur ne peut pas ou ne traitera pas la demande en raison de quelque chose qui est perçu comme une erreur client (par exemple, une syntaxe de demande incorrecte, un cadrage de message de demande invalide ou un routage de demande trompeur).

Comme la demande contient une valeur en double (valeur qui existe déjà), elle peut être perçue comme une erreur client. Besoin de modifier la demande avant le prochain essai.
En considérant ces faits, nous pouvons conclure que HTTP STATUS 400 Bad Request.

— Mohammed Safeer
source

1

Bad Request signifie qu'il y a un problème inhérent à la syntaxe du paquet. Si, dans un autre contexte (comme la ressource qui n'existe pas déjà), le paquet réussirait, alors il ne devrait pas renvoyer l'erreur 400.

— Grant Gryczan

1

Qu'en est-il de 208 - http://httpstatusdogs.com/208-already-reported ? Est-ce une option?

À mon avis, si la seule chose est une ressource répétée, aucune erreur ne devrait être soulevée. Après tout, il n'y a aucune erreur ni côté client ni côté serveur.

— Fernando Ferreira
source

Ce n'est pas une option car vous souhaitez ajouter un certain élément dont l'ID existe déjà. Vous essayez donc d'ajouter quelque chose, mais c'est déjà là. Un OK ne s'appliquerait que si l'ensemble de données était agrandi. Ajouter quelque chose -> Ok je n'ai rien ajouté. Ne correspond pas, je suppose.

— Martin Kersten

Comme je l'ai dit, je ne pense pas que ce soit une erreur. Mais je vois l'intérêt de @martin

— Fernando Ferreira

Si la ressource n'est pas créée avec succès, il y a par définition une erreur.

— Grant Gryczan

POST est également utilisé pour ajouter des données. C'est par définition , pas une erreur .

— Suncat2000

@ Suncat2000 Même si c'est le cas, si les données ne sont pas correctement ajoutées, il y a toujours une erreur. Et si la ressource existe déjà, aucune donnée ne sera ajoutée.

— Grant Gryczan

0

Dans votre cas, vous pouvez utiliser 409 Conflict

Et si vous voulez vérifier un autre HTTPscode d'état de la liste ci-dessous

1 ×umed Informatif

100 Continue
101 Switching Protocols
102 Processing

2 × × Succès

200 OK
201 Created
202 Accepted
203 Non-authoritative Information
204 No Content
205 Reset Content
206 Partial Content
207 Multi-Status
208 Already Reported
226 IM Used

Redirection 3 ×

300 Multiple Choices
301 Moved Permanently
302 Found
303 See Other
304 Not Modified
305 Use Proxy
307 Temporary Redirect
308 Permanent Redirect

Erreur client 4 ×umed

400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed
413 Payload Too Large
414 Request-URI Too Long
415 Unsupported Media Type
416 Requested Range Not Satisfiable
417 Expectation Failed
418 I’m a teapot
421 Misdirected Request
422 Unprocessable Entity
423 Locked
424 Failed Dependency
426 Upgrade Required
428 Precondition Required
429 Too Many Requests
431 Request Header Fields Too Large
444 Connection Closed Without Response
451 Unavailable For Legal Reasons
499 Client Closed Request

Erreur du serveur 5 ×umed

500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported
506 Variant Also Negotiates
507 Insufficient Storage
508 Loop Detected
510 Not Extended
511 Network Authentication Required
599 Network Connect Timeout Error

— Abd Abughazaleh
source