Codice di risposta HTTP per POST quando la risorsa esiste già

842

Sto costruendo un server che consente ai client di archiviare oggetti. Tali oggetti sono interamente costruiti sul lato client, completi di ID oggetto che sono permanenti per l'intera durata dell'oggetto.

Ho definito l'API in modo che i client possano creare o modificare oggetti usando PUT:

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

{json representation of the object}

{Id} è l'ID oggetto, quindi fa parte dell'URI di richiesta.

Ora sto anche considerando la possibilità di consentire ai clienti di creare l'oggetto utilizzando POST:

POST /objects/ HTTP/1.1
...

{json representation of the object, including ID}

Poiché POST è inteso come operazione "append", non sono sicuro di cosa fare nel caso in cui l'oggetto sia già presente. Devo trattare la richiesta come richiesta di modifica o devo restituire un codice di errore (quale)?

rest http http-status-codes

— VMJ
fonte

5

A partire da giugno 2016 FB imposta in modo palese 200 sulla registrazione quando esiste un'e-mail

— Green

4

L'API Github restituisce 422 quando tenta di creare una risorsa (team / repository) con un nome che è già in uso

— Ken,

1

Dipende se si considera l'esistenza dell'oggetto un errore o meno. Se si elabora l'appendice, 200 o 204 sono i codici di risposta più appropriati.

— Suncat2000,

1057

Il mio sentimento è 409 Conflictil più appropriato, tuttavia, raramente visto in natura ovviamente:

Impossibile completare la richiesta a causa di un conflitto con lo stato corrente della risorsa. Questo codice è consentito solo nelle situazioni in cui è previsto che l'utente possa essere in grado di risolvere il conflitto e inviare nuovamente la richiesta. Il corpo della risposta DOVREBBE includere informazioni sufficienti affinché l'utente possa riconoscere l'origine del conflitto. Idealmente, l'entità di risposta dovrebbe includere informazioni sufficienti per l'utente o l'agente utente per risolvere il problema; tuttavia, ciò potrebbe non essere possibile e non è necessario.

È più probabile che si verifichino conflitti in risposta a una richiesta PUT. Ad esempio, se si utilizzava il controllo delle versioni e l'entità in fase di PUT includeva modifiche a una risorsa in conflitto con quelle fatte da una richiesta precedente (di terze parti), il server potrebbe utilizzare la risposta 409 per indicare che non è possibile completare la richiesta . In questo caso, l'entità della risposta conterrebbe probabilmente un elenco delle differenze tra le due versioni in un formato definito dal Content-Type di risposta.

— Wrikken
fonte

11

perché non scegliere 400 Bad Request? Per me questo sembra un po 'un errore di convalida (stai fornendo un payload errato con ID illegale).

— manuel aldana,

314

400 => "La richiesta non è stata compresa dal server a causa di una sintassi non corretta" . E il server comprende perfettamente, ma non è in grado di conformarsi a causa di un conflitto. Non c'è nulla di sbagliato nella richiesta e nella sintassi, solo un problema di dati. Un 400 mi farebbe immediatamente credere che l'intero meccanismo che sto usando sia difettoso, anziché solo i dati.

— Wrikken,

42

@Wrikken Non è più corretto. HTTP 400 è stato modificato in RFC 7231 per indicare "il server non può o non elabora la richiesta a causa di qualcosa che viene percepito come un errore del client (ad es. Sintassi della richiesta non corretta, framing del messaggio di richiesta non valido o instradamento della richiesta ingannevole)." Non sto dicendo che 400 è un uso corretto in questo caso, ma potrebbe essere corretto con la nuova definizione di 400.

— javajavajavajavajava

19

@javajavajavajavajava: ancora, i dati duplicati non sono un "errore client" nella mia mente, ma questo è ovviamente negli occhi di chi guarda.

— Wrikken,

21

Ritorno HTTP 409con Locationun'intestazione che punta alla risorsa esistente / in conflitto.

— Gili,

100

Secondo RFC 7231 , può essere usato un 303 Vedi Altro Se il risultato dell'elaborazione di un POST sarebbe equivalente a una rappresentazione di una risorsa esistente .

— nullius
fonte

4

Secondo me, questa potrebbe essere una risposta accettata. Sebbene "MAGGIO" indichi un elemento completamente opzionale, è l'unico codice di risposta suggerito dalla documentazione ufficiale RFC 7231 .

— Nando,

16

Questa è la risposta più RESTful.

— Seth,

6

Penso che il contesto sia importante. Ad esempio: la restituzione di un 303 implica un reindirizzamento alla risorsa trovata necessaria. Ciò potrebbe avere senso in una chiamata da server a server, ma se si eseguisse un processo di registrazione utente, non avrebbe alcun senso.

— Sinaesthetic

11

Scusa, sto effettuando il downgrade di questo. Gli HTTP 300 riguardano il reindirizzamento e il reindirizzamento a un altro oggetto che probabilmente ha proprietà diverse sarebbe molto fuorviante.

— Michael Scheper,

6

Non devi essere dispiaciuto. Tuttavia, se la rappresentazione è equivalente a una risorsa esistente, come può avere proprietà diverse? E anche se avesse, come sarebbe un reindirizzamento fuorviante? L'OP dice: non sono sicuro di cosa fare nel caso in cui l'oggetto sia già lì. In realtà è lo "stesso" oggetto. Perché un reindirizzamento sarebbe fuorviante? Stai parlando di un altro oggetto che nella mente dell'OP chiaramente non lo è.

— Nullius,

86

Personalmente vado con l'estensione WebDAV 422 Unprocessable Entity.

Secondo RFC 4918

Il 422 Unprocessable Entitycodice di stato indica che il server comprende il tipo di contenuto dell'entità richiesta (quindi un 415 Unsupported Media Typecodice di stato è inappropriato) e la sintassi dell'entità richiesta è corretta (quindi un 400 Bad Requestcodice di stato è inappropriato) ma non è stato in grado di elaborare le istruzioni contenute.

— Gareth
fonte

19

Questo è un pensiero interessante e mi ha spinto a leggere finalmente il WebDAV RFC. Tuttavia, penso che il significato di 422 sia che la richiesta e l'entità inclusa erano sintatticamente corrette ma semanticamente non avevano senso.

— vmj

4

JSON malformato non è un'entità sintatticamente corretta, quindi 422mi

— sembra

7

Non vorrei andare con questo. Dallo stesso URL a cui si fa riferimento nella risposta: "Ad esempio, questa condizione di errore può verificarsi se un corpo di richiesta XML contiene istruzioni XML ben formate (cioè sintatticamente corrette), ma semanticamente errate". Questo è il vero significato di un'entità non elaborabile, diversamente dal caso in cui si inviano entità di richiesta completamente valide con sintassi E semantica valide, ma l'unico problema è che è in conflitto con un'entità esistente. In realtà, se la semantica dell'entità richiesta non fosse valida, non dovrebbe esserci affatto un'entità simile simile.

— Tamer Shlash il

1

Aggiungendo al commento Tamer, se la seconda richiesta fosse la prima, avrebbe avuto successo, cosa impossibile se ciò fosse semanticamente corretto. Quindi nella semantica corretta non si applica qui.

— Harish,

4

@Tamer Perché sì? Il comando "Crea l'oggetto xy" è sintatticamente corretto. È semanticamente corretto solo se è possibile creare l'oggetto xy. Se l'oggetto xy esiste già, non può più essere creato, quindi si tratta di un errore semantico.

— Hagen von Eitzen,

48

Riguarda il contesto e anche chi è responsabile della gestione dei duplicati nelle richieste (server o client o entrambi)

Se il server punta semplicemente il duplicato , guarda 4xx:

400 Richiesta errata: quando il server non elabora una richiesta perché è evidente un errore del client
409 Conflitto: se il server non elaborerà una richiesta, ma il motivo non è colpa del client
...

Per la gestione implicita dei duplicati, guarda 2XX:

200 OK
201 creato
...

se il server dovrebbe restituire qualcosa , guarda 3XX:

302 trovati
303 Vedi Altro
...

quando il server è in grado di puntare la risorsa esistente, implica un reindirizzamento.

Se quanto sopra non è abbastanza, è sempre una buona pratica preparare qualche messaggio di errore nel corpo della risposta.

— Sławomir Lenart
fonte

2

La richiesta non duplica una risorsa, ma aggiunge dati a una risorsa. Secondo me, la tua è la migliore risposta di tutte.

— Suncat2000,

28

Forse fino a tardi nel gioco, ma mi sono imbattuto in questo problema di semantica durante il tentativo di creare un'API REST.

Per espandere un po 'la risposta di Wrikken, penso che potresti usare uno 409 Conflicto in 403 Forbiddenbase alla situazione - in breve, utilizzare un errore 403 quando l'utente non può fare assolutamente nulla per risolvere il conflitto e completare la richiesta (ad esempio non può inviare un DELETErichiesta di rimuovere esplicitamente la risorsa) o utilizzare 409 se è possibile eseguire un'operazione.

10.4.4 403 Proibito

Il server ha compreso la richiesta, ma si rifiuta di soddisfarla. L'autorizzazione non aiuterà e la richiesta NON DOVREBBE essere ripetuta. Se il metodo di richiesta non era HEAD e il server desidera rendere pubblico il motivo per cui la richiesta non è stata soddisfatta, DOVREBBE descrivere il motivo del rifiuto nell'entità. Se il server non desidera rendere disponibili queste informazioni al client, è possibile utilizzare invece il codice di stato 404 (Not Found).

Al giorno d'oggi, qualcuno dice "403" e viene in mente un problema di autorizzazioni o autenticazione, ma le specifiche dicono che è fondamentalmente il server che dice al client che non lo farà, non chiederlo di nuovo, ed ecco perché il client non dovrebbe 't.

Per quanto riguarda PUTvs. POST...POST dovrebbe essere usato per creare una nuova istanza di una risorsa quando l'utente non ha mezzi per o non dovrebbe creare un identificatore per la risorsa. PUTviene utilizzato quando si conosce l'identità della risorsa.

9.6 PUT

...

La differenza fondamentale tra le richieste POST e PUT si riflette nel diverso significato dell'URI di richiesta. L'URI in una richiesta POST identifica la risorsa che gestirà l'entità chiusa. Tale risorsa potrebbe essere un processo di accettazione dei dati, un gateway verso qualche altro protocollo o un'entità separata che accetta le annotazioni. Al contrario, l'URI in una richiesta PUT identifica l'entità racchiusa nella richiesta: l'agente utente sa cosa è destinato l'URI e il server NON DEVE tentare di applicare la richiesta ad altre risorse. Se il server desidera che la richiesta venga applicata a un URI diverso,

DEVE inviare una risposta 301 (spostata in modo permanente); l'agente dell'utente PUO 'quindi prendere la propria decisione riguardo al reindirizzamento della richiesta.

— p0lar_bear
fonte

7

Penso che 403 Forbidden implichi che, anche se l'utente è autenticato , non è autorizzato a eseguire l'azione richiesta. Non lo userei per errori di validazione. Esempio : non eseguito l'accesso, tento di eliminare qualcosa. Il server mi invia 401 non autorizzato (che ha solo un nome errato, dovrebbe essere 401 non autenticato ). Eseguo l'accesso e riprovo. Questa volta il server controlla i miei permessi, vede che non sono autorizzato e restituisce 403 Proibito . Vedi anche questa domanda .

— Stijn de Witt,

Hm ... vero. Il pensiero qui stava saltando giusto nel dire all'utente che le loro autorizzazioni rendono immutabile la risorsa nel caso d'uso del PO - esiste già, non hai il permesso di fare nulla per risolvere il conflitto, non provare a creare di nuovo la risorsa.

— p0lar_bear,

3

Secondo le specifiche, è implicito che l'errore 409 non può essere restituito da una POSTrichiesta (se usato correttamente), in quanto afferma che dovrebbe essere restituito quando è in conflitto con la risorsa di destinazione . Dal momento che la risorsa di destinazione non è ancora stata inviata, non può essere in conflitto e quindi rispondere con 409 Conflictnon ha alcun senso.

— Grant Gryczan,

1

Non desidero dedurre che un errore 409 non possa essere restituito da un POST, in effetti, desidero inferire il contrario perché "È più probabile che si verifichino conflitti in risposta a una richiesta PUT". sembra indicare che anche altri metodi di richiesta possono utilizzare questo codice. Inoltre, "L'organismo di risposta dovrebbe includere informazioni sufficienti affinché l'utente possa riconoscere l'origine del conflitto. Idealmente, l'entità di risposta dovrebbe includere informazioni sufficienti affinché l'utente o l'agente utente possano risolvere il problema; tuttavia, ciò potrebbe non essere possibile e non richiesto . " ( webdav.org/specs/rfc2616.html#status.409 )

— JWAspin

14

"302 Found" suona logico per me. E la RFC 2616 afferma che non è possibile rispondere a richieste diverse da GET e HEAD (e questo sicuramente include POST)

Ma continua ancora il visitatore a visitare questo URL per ottenere questa risorsa "Trovato", dalla RFC. Per farlo andare direttamente al vero URL "Trovato", si dovrebbe usare "303 Visualizza altro", il che ha senso, ma impone un'altra chiamata per ottenere il seguente URL. Sul lato positivo, questo GET è memorizzabile nella cache.

Penso che userei "303 Vedi altro" . Non so se posso rispondere con la "cosa" trovata nel corpo, ma vorrei farlo per salvare un viaggio di andata e ritorno sul server.

AGGIORNAMENTO: Dopo aver riletto l'RFC, penso ancora che un codice "4XX + 303 trovato" inesistente dovrebbe essere il corretto. Tuttavia, "409 Conflict" è il miglior codice di risposta esistente (come indicato da @Wrikken), forse includendo un'intestazione Location che punta alla risorsa esistente.

— alanjds
fonte

88

Gli stati 3xx sono destinati al reindirizzamento

— Aviram Netanel,

1

"La risorsa richiesta risiede temporaneamente con un URI diverso." da w3.org/Protocols/rfc2616/rfc2616-sec10.html

— statueofmike

1

IMHO, "307 Reindirizzamento temporaneo" è il vero reindirizzamento temporaneo. "302" è ambiguo, ma "TROVATO !!" è il messaggio davvero desiderato qui. Il miglior compromesso inequivocabile è "303 Vedi altro" sulla semantica HTTP. Vorrei andare con "303 Vedi altro".

— Alanjds,

@DavidVartanian Hum ... Non vedo un errore qui. Il client invia una richiesta corretta, ma come dire "Ci dispiace, ma quello che stai cercando di creare qui esiste già QUI"? Sembra un lavoro per circa 3xx. Non è un 4xx per me, in quanto non vi è alcun errore client.

— alanjds,

1

@DavidVartanian Grazie per la discussione. Aggiornata la risposta verso 409 . Il cliente ha torto a chiedere cose impossibili, anche se non sa che è impossibile.

— alanjds,

11

Non penso che dovresti farlo.

Il POST è, come sapete, per modificare la raccolta e viene utilizzato per CREARE un nuovo elemento. Quindi, se invii l'id (penso che non sia una buona idea), dovresti modificare la raccolta, cioè modificare l'elemento, ma è confuso.

Usalo per aggiungere un elemento, senza ID. È la migliore pratica.

Se vuoi acquisire un vincolo UNIQUE (non l'id) puoi rispondere 409, come puoi fare nelle richieste PUT. Ma non l'ID.

— Alfonso Tienda
fonte

Che dire di un oggetto che ha una relazione nella tabella di join? Supponiamo di avere account, prodotto e account_product come tabelle del database. Voglio aggiungere un prodotto a un account, quindi vorrei pubblicare su / account / {id} / product con l'id_prodotto. Se è consentita una sola relazione account-prodotto, cosa devo restituire?

— partkyle

2

Dimentica le tabelle del database. Supponiamo che un prodotto possa essere correlato solo a un account ... Quindi è una o più relazioni. Quindi, POST / product / {id} con {'account': account_id}. Se la cardinalità massima è impostata su '1' (relazione uno a uno) .... Perché sono oggetti di riposo separati? Un errore di cardinalità sarà solo un errore di 400. Mantienilo semplice. Spero di aver capito la tua domanda.

— Alfonso Tienda,

Ho anche posto questa domanda e per me l'ID non è l'ID tecnico nel database ma qualcosa di simile al codice dell'azienda. In questa applicazione un utente gestore può creare aziende e deve fornire loro un codice. Questo è l'ID azienda per l'utente, nonostante il fatto che anche la tabella DB abbia un ID tecnico. Quindi nel mio caso restituirò un 409 se lo stesso codice azienda esiste già.

— AlexCode

@partkyle Smetti di usare i PK come ID pubblici !!

— Sinaesthetic,

Alcune entità hanno vincoli univoci su di esse, non solo l'id. Come un account, non puoi creare un account se l'utente non fornisce il nome utente. E aggiungere un account senza nome utente è ovviamente impossibile

— rocketspacer,

9

Vorrei andare con 422 Unprocessable Entity , che viene utilizzato quando una richiesta non è valida ma il problema non è nella sintassi o nell'autenticazione.

Come argomento contro altre risposte, l'uso di qualsiasi 4xxcodice non di errore implicherebbe che non si tratta di un errore del client, e ovviamente lo è. Per usare un non-4xx codice errore per rappresentare un errore del client non ha alcun senso.

Sembra che 409 Conflictsia la risposta più comune qui, ma, secondo le specifiche, ciò implica che la risorsa esiste già e che i nuovi dati che si stanno applicando ad essa sono incompatibili con il suo stato attuale. Se stai inviando aPOSTrichiedere, ad esempio, un nome utente già utilizzato, che non sia effettivamente in conflitto con la risorsa di destinazione, poiché la risorsa di destinazione (la risorsa che si sta tentando di creare) non è stata ancora pubblicata. È un errore specifico per il controllo della versione, quando esiste un conflitto tra la versione della risorsa memorizzata e la versione della risorsa richiesta. È molto utile a tale scopo, ad esempio quando il client ha memorizzato nella cache una versione precedente della risorsa e invia una richiesta basata su quella versione errata che non sarebbe più valida a determinate condizioni. "In questo caso, la rappresentazione della risposta conterrebbe probabilmente informazioni utili per unire le differenze in base alla cronologia delle revisioni." La richiesta di creare un altro utente con quel nome utente è semplicemente non elaborabile, non avendo nulla a che fare con il controllo della versione.

Per la cronaca, 422 è anche il codice di stato utilizzato da GitHub quando si tenta di creare un repository con un nome già in uso.

— Grant Gryczan
fonte

422 è una specifica webdav, quindi non consiglierei di usarla per un'API REST

— rwenz3l

7

Penso che per REST, devi solo prendere una decisione sul comportamento di quel particolare sistema nel qual caso, penso che la risposta "giusta" sarebbe una delle risposte di un paio fornite qui. Se desideri che la richiesta si interrompa e si comporti come se il client avesse commesso un errore che deve correggere prima di continuare, usa 409. Se il conflitto non è poi così importante e vuoi che la richiesta continui, rispondi reindirizzando il client per l'entità che è stata trovata. Penso che le API REST appropriate dovrebbero reindirizzare (o almeno fornire l'intestazione della posizione) all'endpoint GET per quella risorsa dopo un POST, quindi questo comportamento darebbe un'esperienza coerente.

EDIT: Vale anche la pena notare che dovresti prendere in considerazione un PUT poiché stai fornendo l'ID. Quindi il comportamento è semplice: "Non mi interessa cosa c'è adesso, metti questa cosa lì". Significato, se non c'è nulla, verrà creato; se c'è qualcosa, verrà sostituito. Penso che un POST sia più appropriato quando il server gestisce quell'ID. Separare i due concetti in sostanza ti dice come affrontarlo (cioè PUT è idempotente, quindi dovrebbe sempre funzionare fino a quando il payload viene convalidato, POST crea sempre, quindi se c'è una collisione di ID, un 409 descriverà quel conflitto) .

— Sinaesthetic
fonte

Secondo le specifiche, è implicito che l'errore 409 non può essere restituito da una POSTrichiesta (se usato correttamente), in quanto afferma che dovrebbe essere restituito quando è in conflitto con la risorsa di destinazione . Dal momento che la risorsa di destinazione non è ancora stata inviata, non può essere in conflitto e quindi rispondere con 409 Conflictnon ha alcun senso.

— Grant Gryczan,

Imo discutibile. Se pubblichi su / utenti, la risorsa è la raccolta anziché il singolo record / utenti / {id}

— Sinaesthetic

È un errore specifico per il controllo della versione, quando esiste un conflitto tra la versione della risorsa memorizzata e la versione della risorsa richiesta. È molto utile a tale scopo, ad esempio quando il client ha memorizzato nella cache una versione precedente della risorsa e invia una richiesta basata su quella versione errata che non sarebbe più valida a determinate condizioni. "In questo caso, la rappresentazione della risposta conterrebbe probabilmente informazioni utili per unire le differenze in base alla cronologia delle revisioni."

— Concedi Gryczan il

Mi piace usare il tuo suggerimento PUT.

— Concedi Gryczan il

4

Un altro potenziale trattamento sta usando PATCH dopo tutto. Un PATCH è definito come qualcosa che cambia lo stato interno e non è limitato all'aggiunta.

PATCH risolverebbe il problema consentendo di aggiornare elementi già esistenti. Vedi: RFC 5789: PATCH

— Martin Kersten
fonte

2

La patch è come PUT ma non è una sostituzione completa. Viene utilizzato per modificare un pezzo della risorsa come l'aggiunta, la rimozione o la modifica di un singolo elemento della risorsa anziché sostituirlo nel suo insieme.

— Sinaesthetic,

4

Perché non un 202 accettato ? È una richiesta OK (200s), non ci sono stati errori client (400s), di per sé.

Da 10 definizioni del codice di stato :

"202 Accettato. La richiesta è stata accettata per l'elaborazione, ma l'elaborazione non è stata completata."

... perché non aveva bisogno di essere completato, perché esisteva già. Il cliente non sa che esiste già, non ha fatto nulla di male.

Mi sto appoggiando a lanciare un 202, e restituendo contenuti simili a quello che /{resource}/{id}sarebbe tornato un GET .

— Phillip Harrington
fonte

21

Questa risposta è sbagliata 202 significa che il server non ha riscontrato un problema con la richiesta, ma ha scelto di elaborare la richiesta dopo aver risposto. Significa anche che si aspetta che l'elaborazione abbia esito positivo. Nel nostro caso il server sa che l'elaborazione non riuscirà, quindi 202 è la risposta sbagliata.

— Adrian,

4

Un esempio di 202 sarebbe una coda o una sottoscrizione. In altre parole, il risultato della richiesta potrebbe non essere immediatamente disponibile se si dovesse interrogare in questo momento.

— Sinaestetico il

1

Ciò sarebbe appropriato se il server stava ancora elaborando la richiesta. 200 o 204 sarebbero più comuni. Poiché l'OP sta facendo una richiesta di aggiunta, l'esistenza dell'oggetto è una condizione prevista e non un errore.

— Suncat2000,

Non ha senso dire al cliente che la richiesta è stata accettata perché sai già che non lo era!

— lucastamoios,

1

@Adrian e lucastamoios penso che entrambi pensiate che il server legga in modo sincrono dal database, prima di fornire la risposta. Questo non è sempre il caso, quindi questa risposta non è "sbagliata", poiché il server non "sempre" conosce il record esistente. Questo è molto vero nei sistemi asincroni in cui il livello API registra semplicemente le richieste per l'elaborazione da parte dei lavoratori in background.

— gsaslis,

2

Ci siamo imbattuti in questa domanda mentre controllavo il codice corretto per record duplicati.

Perdonate la mia ignoranza ma non capisco perché tutti ignorino il codice "300" che dice chiaramente "scelta multipla" o "ambiguo"

Secondo me questo sarebbe il codice perfetto per costruire un sistema non standard o particolare per il tuo uso personale. Potrei anche sbagliarmi!

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

— hitin
fonte

La mia comprensione: "il codice di stato indica che la risorsa di destinazione ha più di una rappresentazione ... vengono fornite informazioni sulle alternative in modo che l'utente (o l'agente utente) possa selezionare una rappresentazione preferita reindirizzando la sua richiesta a una o più di quelle identificatori "Stiamo esplicitamente cercando di impedire più di una rappresentazione. Non ci sono opzioni Non ci sono alternative tra cui scegliere il cliente. Il client deve inviare nuovamente con un ID diverso. Detto questo, si dovrebbe anche considerare se si dovrebbero generare ID univoci nel client rispetto al server.

— musicin3d

Semanticamente, il client sta dicendo "Crea questo" e il server risponde dicendo "Vai qui". La conversazione non ha alcun senso. È quasi come se il server stesse dicendo al client di "pubblicare in questa posizione". I 300 sono più una risposta più appropriata a una richiesta GET o a un POST nel caso in cui il server stia rispondendo con "Ok l'ho creato ed è qui" ..

— Sinaesthetic

2

Più probabilmente lo è 400 Bad Request

6.5.1. 400 Richiesta non valida

Il codice di stato 400 (Richiesta errata) indica che il server non può o non elabora la richiesta a causa di qualcosa che viene percepito come un errore del client (ad es. Sintassi della richiesta non valida, framing del messaggio di richiesta non valido o instradamento della richiesta ingannevole).

Poiché la richiesta contiene un valore duplicato (valore già esistente), può essere percepita come un errore client. È necessario modificare la richiesta prima del prossimo tentativo.
Considerando questi fatti possiamo concludere come HTTP STATUS 400 Bad Request.

— Mohammed Safeer
fonte

1

Richiesta errata significa che c'è un problema intrinseco con la sintassi del pacchetto. Se, in un altro contesto (come la risorsa non già esistente), il pacchetto avesse esito positivo, non dovrebbe restituire l'errore 400.

— Concedi Gryczan il

1

Che dire di 208: http://httpstatusdogs.com/208- già segnalato ? È un'opzione?

Secondo me, se l'unica cosa è una risorsa di ripetizione, non dovrebbe essere sollevato alcun errore. Dopotutto, non ci sono errori né sul lato client né sul lato server.

— Fernando Ferreira
fonte

Questa non è un'opzione in quanto desideri aggiungere un determinato elemento quale ID è già esistente. Quindi provi ad aggiungere qualcosa ma questo è già lì. Un OK verrebbe applicato solo se il set di dati fosse cresciuto. Aggiungi qualcosa -> Ok, non ho aggiunto nulla. Non va bene, immagino.

— Martin Kersten,

Come ho detto, non credo che questo sia un errore. Ma vedo il punto di @martin

— Fernando Ferreira, il

Se la risorsa non viene creata correttamente, per definizione c'è un errore.

— Grant Gryczan,

Il POST viene utilizzato anche per aggiungere dati. Questo è per definizione , non un errore .

— Suncat2000,

@ Suncat2000 Anche se questo è il caso, se i dati non vengono aggiunti correttamente, c'è ancora un errore. E se la risorsa esiste già, non verranno aggiunti dati.

— Concedi Gryczan il

0

Nel tuo caso puoi usare 409 Conflict

E se si desidera controllare un altro HTTPscodice di stato dall'elenco seguente

1 ×× Informativo

100 Continue
101 Switching Protocols
102 Processing

2 ×× Successo

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

Reindirizzamento 3 ××

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

4 ×× Errore del client

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

5 ×× Errore del server

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
fonte