Código de respuesta HTTP para POST cuando el recurso ya existe

842

Estoy construyendo un servidor que permite a los clientes almacenar objetos. Esos objetos están completamente construidos en el lado del cliente, completos con ID de objetos que son permanentes durante toda la vida útil del objeto.

He definido la API para que los clientes puedan crear o modificar objetos usando PUT:

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

{json representation of the object}

El {id} es el ID del objeto, por lo que forma parte del URI de solicitud.

Ahora, también estoy considerando permitir que los clientes creen el objeto usando POST:

POST /objects/ HTTP/1.1
...

{json representation of the object, including ID}

Dado que POST se entiende como operación "agregar", no estoy seguro de qué hacer en caso de que el objeto ya esté allí. ¿Debo tratar la solicitud como una solicitud de modificación o debo devolver algún código de error (que)?

rest http http-status-codes

— vmj
fuente

55

A partir de junio de 2016, FB establece abiertamente 200 en el registro cuando existe un correo electrónico

— Verde

44

La API de Github devuelve 422 cuando intenta crear un recurso (equipo / repositorio) con un nombre que ya está en uso

— Ken

1

Depende si considera que la existencia del objeto es un error o no. Si procesa el anexo, 200 o 204 son los códigos de respuesta más apropiados.

— Suncat2000

1058

Mi sentimiento es 409 Conflictel más apropiado, sin embargo, rara vez se ve en la naturaleza, por supuesto:

La solicitud no se pudo completar debido a un conflicto con el estado actual del recurso. Este código solo se permite en situaciones en las que se espera que el usuario pueda resolver el conflicto y volver a enviar la solicitud. El cuerpo de respuesta DEBE incluir suficiente información para que el usuario reconozca la fuente del conflicto. Idealmente, la entidad de respuesta incluiría suficiente información para que el usuario o agente de usuario solucione el problema; sin embargo, eso podría no ser posible y no es obligatorio.

Es más probable que ocurran conflictos en respuesta a una solicitud PUT. Por ejemplo, si se usaban versiones y la entidad que se PUT incluía cambios en un recurso que entran en conflicto con los realizados por una solicitud anterior (de terceros), el servidor podría usar la respuesta 409 para indicar que no puede completar la solicitud . En este caso, la entidad de respuesta probablemente contendría una lista de las diferencias entre las dos versiones en un formato definido por el Tipo de contenido de respuesta.

— Wrikken
fuente

11

¿Por qué no optar por 400 Bad Request? Para mí, esto se parece un poco a un error de validación (está proporcionando una carga útil incorrecta con una identificación ilegal).

— manuel aldana

314

400 => "El servidor no pudo entender la solicitud debido a una sintaxis incorrecta" . Y el servidor entiende perfectamente, pero no puede cumplir debido a un conflicto. No hay nada malo con la solicitud y la sintaxis, solo un problema de datos. Un 400 instantáneamente me haría creer que todo el mecanismo que estoy usando es defectuoso, en lugar de solo los datos.

— Escrito el

42

@Wrikken Eso ya no es correcto. HTTP 400 se cambió en RFC 7231 para significar "el servidor no puede o no procesará la solicitud debido a algo que se percibe como un error del cliente (por ejemplo, sintaxis de solicitud con formato incorrecto, enmarcado de mensaje de solicitud no válido o enrutamiento de solicitud engañoso)". No digo que 400 sea el uso correcto en este caso, pero podría ser correcto con la nueva definición de 400.

— javajavajavajavajava

19

@javajavajavajavajava: aún así, los datos duplicados no son un "error del cliente" en mi mente, pero eso está en el ojo del espectador, por supuesto.

— Escrito el

21

Regreso HTTP 409con un Locationencabezado apuntando al recurso existente / conflictivo.

— Gili

100

De acuerdo con RFC 7231 , un 303 Ver otro PUEDE usarse si el resultado del procesamiento de un POST sería equivalente a una representación de un recurso existente .

— Nulo
fuente

44

En mi opinión, esta podría ser la respuesta aceptada. Aunque "MAYO" indica un elemento completamente opcional, es el único código de respuesta sugerido por la documentación oficial del RFC 7231 .

— Nando

16

Esta es la respuesta más descansada.

— Seth

66

Creo que el contexto es importante. Por ejemplo: devolver un 303 implica que se necesita una redirección al recurso encontrado. Eso podría tener sentido en una llamada de servidor a servidor, pero si estuviera ejecutando un proceso de registro de usuario, no tendría ningún sentido.

— Sinaesthetic

11

Lo siento, estoy rechazando esto. Los HTTP 300 tratan de redireccionar, y redirigir a otro objeto que probablemente tenga propiedades diferentes sería muy engañoso.

— Michael Scheper

66

No tienes que disculparte. Sin embargo, si la representación es equivalente a un recurso existente, ¿cómo puede tener diferentes propiedades? E incluso si lo hubiera hecho, ¿cómo sería engañosa una redirección? El OP dice: no estoy seguro de qué hacer en caso de que el objeto ya esté allí. De hecho, es el "mismo" objeto. ¿Por qué una redirección sería engañosa? Estás hablando de otro objeto que en la mente del OP claramente no lo es.

— Nullius

86

Personalmente voy con la extensión WebDAV 422 Unprocessable Entity.

De acuerdo con RFC 4918

El 422 Unprocessable Entitycódigo de estado significa que el servidor comprende el tipo de contenido de la entidad de solicitud (por lo tanto, un 415 Unsupported Media Typecódigo de estado es inapropiado), y la sintaxis de la entidad de solicitud es correcta (por lo tanto, un 400 Bad Requestcódigo de estado es inapropiado) pero no pudo procesar las instrucciones contenidas.

— Gareth
fuente

19

Este es un pensamiento interesante y me impulsó a leer finalmente el RFC WebDAV. Sin embargo, creo que el significado de 422 es que la solicitud y la entidad incluida eran sintácticamente correctas pero semánticamente no tenían sentido.

— vmj

44

Malformado JSON no es una entidad sintácticamente correcta, por lo 422que me parece extraño ...

— awendt

77

No iría con esto. De la misma URL a la que se hace referencia en la respuesta: "Por ejemplo, esta condición de error puede ocurrir si un cuerpo de solicitud XML contiene instrucciones XML bien formadas (es decir, sintácticamente correctas), pero semánticamente erróneas". Este es el significado real de una entidad no procesable, a diferencia del caso cuando envía una entidad de solicitud completamente válida con sintaxis Y semántica válidas, pero el único problema es que entra en conflicto con una entidad existente. En realidad, si la semántica de la entidad de solicitud no fuera válida, no debería existir una entidad existente similar.

— Tamer Shlash

1

Agregando al comentario de Tamer, si la segunda solicitud llega primero, entonces tendrá éxito, lo que no será posible si eso fuera semánticamente correcto. Por lo tanto, en la semántica correcta no se aplicaría aquí.

— Harish

44

@Tamer ¿Por qué así? El comando "Crear objeto xy" es sintácticamente correcto. Es semánticamente correcto solo si es posible crear el objeto xy. Si el objeto xy ya existe, ya no se puede crear, por lo tanto, este es un error semántico.

— Hagen von Eitzen

48

Se trata de contexto , y también de quién es responsable de manejar los duplicados en las solicitudes (servidor o cliente o ambos)

Si el servidor solo apunta el duplicado , mire 4xx:

400 Solicitud incorrecta: cuando el servidor no procesará una solicitud porque es evidente un error del cliente
409 Conflicto: si el servidor no procesará una solicitud, pero el motivo no es culpa del cliente
...

Para el manejo implícito de duplicados, mire 2XX:

200 OK
201 Creado
...

Si se espera que el servidor devuelva algo , mire 3XX:

302 encontrado
303 Ver otros
...

cuando el servidor puede apuntar el recurso existente, implica una redirección.

Si lo anterior no es suficiente, siempre es una buena práctica preparar algún mensaje de error en el cuerpo de la respuesta.

— Sławomir Lenart
fuente

2

La solicitud no está duplicando un recurso, está agregando datos a uno. En mi opinión, la tuya es la mejor respuesta de todas.

— Suncat2000

28

Tal vez tarde en el juego, pero me topé con este problema de semántica al intentar hacer una API REST.

Para ampliar un poco la respuesta de Wrikken, creo que podría usar cualquiera 409 Conflicto 403 Forbiddendependiendo de la situación; en resumen, use un error 403 cuando el usuario no puede hacer absolutamente nada para resolver el conflicto y completar la solicitud (por ejemplo, no puede enviar un DELETEsolicitud para eliminar explícitamente el recurso), o use 409 si algo podría hacerse.

10.4.4 403 Prohibido

El servidor entendió la solicitud, pero se niega a cumplirla. La autorización no ayudará y la solicitud NO DEBE repetirse. Si el método de solicitud no era HEAD y el servidor desea hacer público el motivo por el cual la solicitud no se ha cumplido, DEBERÍA describir el motivo del rechazo en la entidad. Si el servidor no desea que esta información esté disponible para el cliente, se puede usar el código de estado 404 (No encontrado).

Hoy en día, alguien dice "403" y me viene a la mente un problema de permisos o autenticación, pero la especificación dice que es básicamente el servidor que le dice al cliente que no lo va a hacer, no lo pregunte nuevamente, y esta es la razón por la cual el cliente no debería 't.

En cuanto a PUTvs. POST... POSTdebe usarse para crear una nueva instancia de un recurso cuando el usuario no tiene medios para o no debe crear un identificador para el recurso. PUTse usa cuando se conoce la identidad del recurso.

9.6 PONER

...

La diferencia fundamental entre las solicitudes POST y PUT se refleja en el significado diferente del Request-URI. El URI en una solicitud POST identifica el recurso que manejará la entidad adjunta. Ese recurso podría ser un proceso de aceptación de datos, una puerta de enlace a algún otro protocolo o una entidad separada que acepte anotaciones. Por el contrario, el URI en una solicitud PUT identifica la entidad adjunta a la solicitud: el agente de usuario sabe a qué se destina el URI y el servidor NO DEBE intentar aplicar la solicitud a otro recurso. Si el servidor desea que la solicitud se aplique a un URI diferente,

DEBE enviar una respuesta 301 (movida permanentemente); el agente de usuario PUEDE tomar su propia decisión con respecto a redirigir o no la solicitud.

— p0lar_bear
fuente

77

Creo que 403 Prohibido implica que, aunque el usuario esté autenticado , no está autorizado para ejecutar la acción solicitada. No lo usaría para errores de validación. Ejemplo : sin iniciar sesión, intento eliminar algo. El servidor me envía 401 no autorizado (que tiene un nombre incorrecto, debe ser 401 no autenticado ). Me conecto e intento nuevamente. Esta vez, el servidor verifica mis permisos, ve que no estoy permitido y devuelve 403 Prohibido . También vea esta pregunta .

— Stijn de Witt

Hm ... cierto. La idea aquí fue saltar directamente a decirle al usuario que sus autorizaciones hacen que el recurso sea inmutable en el caso de uso del OP: ya existe, no tiene permiso para hacer nada para resolver el conflicto, no intente crear el recurso nuevamente.

— p0lar_bear

3

De acuerdo con la especificación, está implícito que el error 409 no puede ser devuelto por una POSTsolicitud (cuando se usa correctamente), ya que establece que debería devolverse cuando entra en conflicto con el recurso de destino . Como el recurso de destino aún no se ha publicado, no puede entrar en conflicto y, por lo tanto, responder 409 Conflictno tiene ningún sentido.

— Grant Gryczan

1

No inferiría que un error 409 no puede ser devuelto por POST, de hecho, inferiría lo contrario porque "Es más probable que ocurran conflictos en respuesta a una solicitud PUT". parece indicar que otros métodos de solicitud también pueden usar este código. Además, "El cuerpo de respuesta debe incluir suficiente información para que el usuario reconozca la fuente del conflicto. Idealmente, la entidad de respuesta debería incluir suficiente información para que el usuario o agente de usuario solucione el problema; sin embargo, eso podría no ser posible y es no requerido ". ( webdav.org/specs/rfc2616.html#status.409 )

— JWAspin

14

"302 encontrado" me parece lógico. Y el RFC 2616 dice que PUEDE ser respondido para otras solicitudes que no sean GET y HEAD (y esto seguramente incluye POST)

Pero aún mantiene al visitante yendo a esta URL para obtener este recurso "Encontrado", por el RFC. Para que vaya directamente a la URL "Encontrada" real, se debe usar "303 Ver otra", lo cual tiene sentido, pero obliga a otra llamada a OBTENER la siguiente URL. En el lado bueno, este GET es almacenable en caché.

Creo que usaría "303 See Other" . No sé si puedo responder con la "cosa" que se encuentra en el cuerpo, pero me gustaría hacerlo para guardar un viaje de ida y vuelta al servidor.

ACTUALIZACIÓN: Después de volver a leer el RFC, sigo pensando que un código inexistente "4XX + 303 encontrado" debería ser el correcto. Sin embargo, el "Conflicto 409" es el mejor código de respuesta existente (como lo señaló @Wrikken), tal vez incluyendo un encabezado de ubicación que apunta al recurso existente.

— alanjds
fuente

88

Los estados 3xx están destinados a la redirección

— Aviram Netanel

1

"El recurso solicitado reside temporalmente bajo un URI diferente". de w3.org/Protocols/rfc2616/rfc2616-sec10.html

— statueofmike

1

En mi humilde opinión, "Redirección temporal 307" es la redirección temporal real. "302" es ambiguo, pero "ENCONTRADO !!" es el mensaje realmente deseado aquí. El mejor compromiso inequívoco es "303 See Other" en la semántica HTTP. Yo iría con "303 See Other".

— alanjds

@DavidVartanian Hum ... No veo un error aquí. El cliente envía una solicitud correcta, pero ¿cómo decir "Lo siento, pero lo que está intentando crear aquí ya existe AQUÍ"? Parece un trabajo para algunos 3xx. No es un 4xx para mí, ya que no hay error del cliente.

— alanjds

1

@DavidVartanian Gracias por la discusión. Se actualizó la respuesta hacia 409 . El cliente se equivoca al pedir cosas imposibles, incluso si no sabe que es imposible.

— alanjds

11

No creo que debas hacer esto.

La POST es, como saben, para modificar la colección y se usa para CREAR un nuevo elemento. Entonces, si envía la identificación (creo que no es una buena idea), debe modificar la colección, es decir, modificar el elemento, pero es confuso.

Úselo para agregar un elemento, sin identificación. Es la mejor práctica.

Si desea capturar una restricción ÚNICA (no la identificación), puede responder 409, como puede hacer en las solicitudes PUT. Pero no la identificación.

— Alfonso Tienda
fuente

¿Qué pasa con un objeto que tiene una relación de tabla de unión? Digamos que tenemos cuenta, producto y account_product como tablas de base de datos. Quiero agregar un producto a una cuenta, por lo que me gustaría publicar en / account / {id} / product con product_id. Si solo se permite una relación cuenta-producto, ¿qué debo devolver?

— Partkyle

2

Olvídate de las tablas de la base de datos. Digamos que un producto solo puede estar relacionado con una cuenta ... Entonces es una relación de uno a muchos. Entonces, POST / product / {id} con {'account': account_id}. Si tiene la cardinalidad máxima establecida en '1' (relación uno a uno) ... ¿Por qué están separados los objetos de descanso? Un error de cardinalidad será solo un error de 400. Mantenlo simple. Espero haber entendido tu pregunta.

— Alfonso Tienda

Acabo de plantear esta pregunta también y para mí la identificación no es la identificación técnica en la base de datos, sino algo así como el código de la empresa. En esta aplicación, un usuario administrador puede crear empresas y debe proporcionarles un código. Esta es la identificación de la compañía para el usuario, a pesar de que la tabla DB también tiene una identificación técnica. Entonces, en mi caso, devolveré un 409 si ya existe el mismo código de compañía.

— AlexCode

@partkyle ¡Deje de usar PK como ID públicas!

— Sinaesthetic

Algunas entidades tienen restricciones únicas, no solo la identificación. Al igual que una cuenta, no puede crear una cuenta si el usuario no proporciona el nombre de usuario. Y agregar una cuenta sin nombre de usuario es obviamente imposible

— rocketspacer

9

Iría con 422 Unprocessable Entity, que se usa cuando una solicitud no es válida pero el problema no está en la sintaxis o la autenticación.

Como argumento en contra de otras respuestas, usar cualquier 4xxcódigo sin error implicaría que no es un error del cliente, y obviamente lo es. Usar un 4xxcódigo sin error para representar un error del cliente simplemente no tiene ningún sentido.

Parece que esa 409 Conflictes la respuesta más común aquí, pero, de acuerdo con la especificación, eso implica que el recurso ya existe y los nuevos datos que está aplicando son incompatibles con su estado actual. Si está enviando unPOSTsolicite, por ejemplo, un nombre de usuario que ya está en uso, no está en conflicto con el recurso de destino, ya que el recurso de destino (el recurso que está intentando crear) aún no se ha publicado. Es un error específicamente para el control de versiones, cuando hay un conflicto entre la versión del recurso almacenado y la versión del recurso solicitado. Es muy útil para ese propósito, por ejemplo, cuando el cliente ha almacenado en caché una versión anterior del recurso y envía una solicitud basada en esa versión incorrecta que ya no sería condicionalmente válida. "En este caso, la representación de la respuesta probablemente contendría información útil para fusionar las diferencias en función del historial de revisiones". La solicitud de crear otro usuario con ese nombre de usuario simplemente no se puede procesar, ya que no tiene nada que ver con el control de versiones.

Para el registro, 422 también es el código de estado que GitHub usa cuando intenta crear un repositorio con un nombre que ya está en uso.

— Grant Gryczan
fuente

422 es especificación webdav, por lo que no recomendaría usar esto para una API REST

— rwenz3l

7

Creo que para REST, solo tiene que tomar una decisión sobre el comportamiento de ese sistema en particular, en cuyo caso, creo que la respuesta "correcta" sería una de las dos respuestas que se dan aquí. Si desea que la solicitud se detenga y se comporte como si el cliente cometiera un error que necesita corregir antes de continuar, utilice 409. Si el conflicto realmente no es tan importante y desea mantener la solicitud en marcha, responda redirigiendo el cliente a la entidad que se encontró. Creo que las API REST adecuadas deberían redirigirse (o al menos proporcionar el encabezado de ubicación) al punto final GET para ese recurso después de una POST de todos modos, por lo que este comportamiento daría una experiencia consistente.

EDITAR: También vale la pena señalar que debe considerar un PUT ya que está proporcionando la identificación. Entonces el comportamiento es simple: "No me importa lo que hay ahora, pon esto aquí". Es decir, si no hay nada allí, se creará; Si hay algo allí, será reemplazado. Creo que una POST es más apropiada cuando el servidor gestiona esa ID. La separación de los dos conceptos básicamente le dice cómo tratarlo (es decir, PUT es idempotente, por lo que siempre debería funcionar siempre que la carga útil se valide, POST siempre crea, por lo que si hay una colisión de ID, entonces un 409 describiría ese conflicto) .

— Sinestésico
fuente

De acuerdo con la especificación, está implícito que el error 409 no puede ser devuelto por una POSTsolicitud (cuando se usa correctamente), ya que establece que debería devolverse cuando entra en conflicto con el recurso de destino . Como el recurso de destino aún no se ha publicado, no puede entrar en conflicto y, por lo tanto, responder 409 Conflictno tiene ningún sentido.

— Grant Gryczan

Debatable imo. Si publica en / users, el recurso es la colección en lugar del registro individual / users / {id}

— Sinaesthetic

Es un error específicamente para el control de versiones, cuando hay un conflicto entre la versión del recurso almacenado y la versión del recurso solicitado. Es muy útil para ese propósito, por ejemplo, cuando el cliente ha almacenado en caché una versión anterior del recurso y envía una solicitud basada en esa versión incorrecta que ya no sería condicionalmente válida. "En este caso, la representación de la respuesta probablemente contendría información útil para fusionar las diferencias en función del historial de revisiones".

— Grant Gryczan

Sin PUTembargo, me gusta su sugerencia de usar .

— Grant Gryczan

4

Otro posible tratamiento es usar PATCH después de todo. Un PATCH se define como algo que cambia el estado interno y no se limita a agregar.

PATCH resolvería el problema permitiéndole actualizar elementos ya existentes. Ver: RFC 5789: PARCHE

— Martin Kersten
fuente

2

El parche es como PUT pero no es un reemplazo completo. Se utiliza para modificar una parte del recurso, como agregar, eliminar o modificar un solo elemento del recurso en lugar de reemplazarlo como un todo.

— Sinaesthetic

3

¿Por qué no un 202 aceptado ? Es una solicitud correcta (200s), no hubo errores del cliente (400s), per se.

De 10 definiciones de código de estado :

"202 aceptado. La solicitud ha sido aceptada para su procesamiento, pero el procesamiento no se ha completado".

... porque no necesitaba completarse, porque ya existía. El cliente no sabe que ya existía, no hicieron nada malo.

Me estoy inclinando por lanzar un 202 y devolver contenido similar al que /{resource}/{id}habría obtenido un GET .

— Phillip Harrington
fuente

21

Esta respuesta es incorrecta. 202 significa que el servidor no encontró un problema con la solicitud, sino que eligió procesar la solicitud después de responder. También significa que espera que el procesamiento sea exitoso. En nuestro caso, el servidor sabe que el procesamiento fallará, por lo que 202 es la respuesta incorrecta.

— Adrian

44

Un ejemplo de 202 sería una cola o suscripción. En otras palabras, el resultado de la solicitud puede no estar disponible de inmediato si tuviera que consultarlo en este momento.

— Sinaesthetic

1

Esto sería apropiado si el servidor todavía estuviera procesando la solicitud. 200 o 204 serían más comunes. Dado que el OP está haciendo una solicitud de adición, la existencia del objeto es una condición esperada y no un error.

— Suncat2000

¡No tiene sentido decirle al cliente que la solicitud fue aceptada porque ya sabe que no lo fue!

— lucastamoios

1

@Adrian y lucastamoios, creo que ambos están asumiendo que el servidor lee sincrónicamente la base de datos, antes de proporcionar la respuesta. Este no es siempre el caso, por lo que esta respuesta no es "incorrecta", ya que el servidor no siempre "sabe" sobre el registro existente. Este es el caso de los sistemas asincrónicos donde la capa api simplemente registra las solicitudes de procesamiento por parte de los trabajadores en segundo plano.

— gsaslis

2

Tropecé con esta pregunta mientras buscaba el código correcto para el registro duplicado.

Disculpe mi ignorancia pero no entiendo por qué todos ignoran el código "300" que claramente dice "opción múltiple" o "Ambiguo"

En mi opinión, este sería el código perfecto para construir un sistema no estándar o particular para su propio uso. ¡También podría estar equivocado!

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

— Golpear en
fuente

Según tengo entendido: "el código de estado indica que el recurso de destino tiene más de una representación ... se proporciona información sobre las alternativas para que el usuario (o agente de usuario) pueda seleccionar una representación preferida al redirigir su solicitud a una o más de esas identificadores "Estamos tratando explícitamente de evitar más de una representación. No hay opciones No hay alternativas para que el cliente elija. El cliente debe volver a enviar con una identificación diferente. Dicho esto, también se debe considerar si se deben generar identificadores únicos en el cliente frente al servidor.

— musicin3d

Semánticamente, el cliente dice "Crear esto" y el servidor responde diciendo "Vaya aquí". La conversación no tiene ningún sentido. Es casi como si el servidor le dijera al cliente que "publique en esta ubicación". Los 300 son más una respuesta más apropiada a una solicitud GET o una POST en el caso de que el servidor responda con "Ok, lo creé y está por aquí" ..

— Sinaesthetic

2

Es más probable que sea 400 Bad Request

6.5.1. 400 Petición Incorrecta

El código de estado 400 (Solicitud incorrecta) indica que el servidor no puede o no procesará la solicitud debido a algo que se percibe como un error del cliente (por ejemplo, sintaxis de solicitud con formato incorrecto, enmarcado de mensaje de solicitud no válido o enrutamiento de solicitud engañoso).

Como la solicitud contiene un valor duplicado (valor que ya existe), se puede percibir como un error del cliente. Necesita cambiar la solicitud antes del próximo intento.
Al considerar estos hechos, podemos concluir como HTTP STATUS 400 Bad Request.

— Mohammed Safeer
fuente

1

Solicitud incorrecta significa que hay un problema inherente con la sintaxis del paquete. Si, en otro contexto (como el recurso aún no existente), el paquete tendría éxito, entonces no debería devolver el error 400.

— Grant Gryczan

1

¿Qué pasa con 208 - http://httpstatusdogs.com/208-already-reported ? ¿Es esa una opción?

En mi opinión, si lo único es un recurso repetido, no se debe generar ningún error. Después de todo, no hay error ni en el lado del cliente o del servidor.

— Fernando Ferreira
fuente

Esta no es una opción, ya que desea agregar un determinado elemento cuya identificación ya existe. Entonces intentas agregar algo pero esto ya está allí. Un OK solo se aplicaría si el conjunto de datos creció. Agregar algo -> Ok, no agregué nada. No encaja, supongo.

— Martin Kersten

Como dije, no creo que esto sea un error. Pero veo el punto de @martin

— Fernando Ferreira

Si el recurso no se crea correctamente, entonces, por definición, hay un error.

— Grant Gryczan

POST también se utiliza para agregar datos. Esto es, por definición , no un error .

— Suncat2000

@ Suncat2000 Incluso dado que ese es el caso, si los datos no se agregan correctamente, todavía hay un error. Y si el recurso ya existe, no se agregarán datos.

— Grant Gryczan

0

En tu caso puedes usar 409 Conflict

Y si desea consultar otros HTTPscódigos de estado de la lista a continuación

1 × aislado informativo

100 Continue
101 Switching Protocols
102 Processing

2 × aislado éxito

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

Redirección de 3 ×

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

Error de cliente 4 ×font>

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 × error del servidor

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
fuente