Código de respuesta HTTP para POST cuando el recurso ya existe
Estoy construyendo un servidor que permite a los clientes almacenar objetos. Esos objetos se construyen completamente en el lado del cliente, con ID de objeto 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 es parte del URI de solicitud.
Ahora, también estoy considerando permitir a los clientes crear el objeto usando POST:
POST /objects/ HTTP/1.1
...
{json representation of the object, including ID}
Dado que POST pretende ser una operación de "añadir", 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 (cuál)?
Mi sensación es 409 Conflictla más apropiada, 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 la respuesta DEBE incluir suficiente información para que el usuario reconozca el origen 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 necesario.
Es más probable que se produzcan conflictos en respuesta a una solicitud PUT. Por ejemplo, si se estuviera utilizando el control de versiones y la entidad que se PUT incluye cambios en un recurso que entran en conflicto con los realizados por una solicitud anterior (de un tercero), 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 la respuesta.
Se trata de contexto y también de quién es responsable de manejar los duplicados de solicitudes (servidor, cliente o ambos).
Si el servidor solo señala el duplicado , mire 4xx:
- 400 Solicitud incorrecta: cuando el servidor no procesa una solicitud porque es una falla obvia del cliente
- Conflicto 409: si el servidor no procesa una solicitud, pero el motivo no es culpa del cliente
- ...
Para el manejo implícito de duplicados, mire 2XX:
- 200 bien
- 201 creado
- ...
Si se espera que el servidor devuelva algo , mire 3XX:
- 302 encontrado
- 303 Ver Otros
- ...
cuando el servidor es capaz de señalar 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.
