Respondiendo a una petición HTTP POST idempotente

Question

Parte de nuestra API RESTful permitirá a los usuarios registrar un artículo con un número de serie. Como el número de serie no es globalmente único, no puede utilizarse como identificador del recurso, por lo que utilizaremos una POST para el recurso padre que generará un identificador, p.

POST /my/items 

<item serial-number="ABCDEF" /> 

En el caso en que el elemento no esté ya registrado, la semántica de HTTP está bien definida. Devolvemos un encabezado de ubicación y el elemento registrado como el cuerpo de la entidad, p.

HTTP 201 Created 
Location: /my/items/1234  

<item id="1234" serial-number="ABCDEF" /> 

Sin embargo, en el caso en que el objeto ya se ha registrado, la API debe ser idempotente y devolver el artículo previamente registrada sin crear una nueva. Mi mejor opción es que devuelva un código de estado 200 OK y use el encabezado Content-Location para indicar de dónde proviene el elemento, p.

HTTP 200 OK 
Content-Location: /my/items/1234  

<item id="1234" serial-number="ABCDEF" /> 

¿Parecería razonable? No estoy del todo claro si la ubicación o la ubicación del contenido es más adecuada en el segundo caso.

Answer 1

Tuve un requisito similar recientemente. Para las operaciones idempotentes PUT es la mejor manera. Tienes razón, hay un desajuste entre el ID externo y el interno. Lo resuelto mediante la creación de un recurso dedicado para el ID de destino externo:

PUT /api-user/{username}/items/{serialNumber} 

Internamente resolverlo como cree en caso de que no tengo tema para 'nombre de usuario' y el número o UPDATE serie 'ABCDEF' en caso de que hago .

En caso de que se tratara de un CREATE, devuelvo 201 para una actualización 200. Además, la carga útil devuelta contiene tanto el ID de fabricación propia como el número de serie externo como sugirió en su carga útil.

Answer 2

Here es una discusión interesante sobre los usos de los dos encabezados. Afirma que Content-Location no está definido para PUT o POST, por lo que la ubicación es posiblemente la mejor opción en su caso. Ciertamente no es claro, pero es mejor.

En general, creo que su enfoque tiene sentido.