2012-06-22 17 views
10

He creado una API que responde a una solicitud POST colocando el contenido del nuevo recurso en el cuerpo de la respuesta y la URL del nuevo recurso en el encabezado de respuesta HTTP de la ubicación.Respuesta REST: ¿debo poner la URL del nuevo recurso en el encabezado, el cuerpo o ambos?

Solicitud de muestra:

POST /api/v1/widgets HTTP/1.1 
Content-type: application/json; 
Accept: application/json; 

{ 
    "name": "[email protected]", 
    "price": "10", 
} 

respuestas de ejemplo:

HTTP 201 Created 
Location: http://example.com/api/v1/widgets/123456 

{ 
    'widget': 
    { 
     'id': "123456", 
     'created': "2012-06-22T12:43:37+0100", 
     'name': "[email protected]", 
     'price': "10", 
    }, 
} 

Alguien ha planteado una cuestión de que la URL también debe estar en el cuerpo de la respuesta. ¿Hay una mejor práctica en esto?

+0

(No dude en matar esto si es demasiado subjetivo - no estoy seguro si esto contraviene el espíritu de SO o no) –

Respuesta

6

Lo pondría en el encabezado (como Ubicación: http://blah.blah.com/blah). También podría incluirlo en su cuerpo si lo desea (en el formato apropiado que esté enviando), y no sería incorrecto.

El atompub REST API suele ser una buena referencia para una buena API REST. Lo ponen en ambos.

HTTP/1.1 201 Created 
Date: Fri, 7 Oct 2005 17:17:11 GMT 
Content-Length: nnn 
Content-Type: application/atom+xml;type=entry;charset="utf-8" 
Location: http://example.org/edit/first-post.atom 
ETag: "c180de84f991g8" 

<?xml version="1.0"?> 
<entry xmlns="http://www.w3.org/2005/Atom"> 
    <title>Atom-Powered Robots Run Amok</title> 
    <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id> 
    <updated>2003-12-13T18:30:02Z</updated> 
    <author><name>John Doe</name></author> 
    <content>Some text.</content> 
    <link rel="edit" 
     href="http://example.org/edit/first-post.atom"/> 
</entry> 
+0

Gracias por la respuesta - tener un punto de referencia como atompub es justo lo que estaba buscando. –

+2

Sí, pero tenga en cuenta que el URI en el cuerpo del ejemplo devuelto de AtomPub que se muestra arriba es realmente un enlace que le dice al receptor qué URI usar si quiere "editar" el recurso (siguiendo el principio HATEOAS). No es, estrictamente hablando, necesariamente el mismo que el URI del recurso en sí (es decir, no necesariamente el mismo que el valor en el encabezado Ubicación: que indica dónde se puede OBTENER el recurso). Sucede que en este ejemplo, el URI para OBTENER el recurso y el utilizado para editar el recurso es el mismo. –

+0

De acuerdo, es bueno saberlo. Yo había supuesto que siempre serían iguales. El OP debería tener esto en cuenta. – smcg

7

Hay una razón para no poner la ubicación (URL) del recurso recién creado) en el cuerpo: la URL es metadatos necesarios para la interacción de mensajes entre los consumidores y servicios de servicios, no es "datos de negocio" . Hay un patrón de diseño SOA llamado "Messaging Metadata" que sugiere que las URL, credenciales de seguridad, identificadores de correlación, ID de transacción y otros datos de contexto de composición y mensajería deben colocarse en encabezados, no en el cuerpo de los mensajes. De hecho, http ya proporciona la ubicación de encabezado estándar para eso.

OTOH, si su servicio REST utiliza HATEOAS, la respuesta puede contener una o más URL que son enlaces directos a las operaciones que desea ofrecer para que los consumidores se vinculen y llamen dinámicamente.

Creo que tener la URL tanto en el encabezado como en el cuerpo es la peor solución. Los datos redundantes son propensos a la inconsistencia a largo plazo.

Cuestiones relacionadas