de versiones de una API REST con XML y JSON Content-Type

Según this excellent presentation en el diseño de interfaces REST, la mejor forma de poner en práctica el control de versiones es utilizar la cabecera Accept, usando algo como:de versiones de una API REST con XML y JSON Content-Type

GET /products HTTP/1.1 
Host: example.com 
Accept: application/vnd.com.myservice.v2+xml

Estos trabajos perfectamente para XML Content-Types, pero es posible usar el mismo esquema para versionar el equivalente a JSON?

Es decir, es posible pedir:

GET /products HTTP/1.1 
Host: example.com 
Accept: application/vnd.com.myservice.v2+json

La respuesta sería algo así como:

HTTP/1.1 200 OK 
Content-Type: application/vnd.com.myservice.v2+xml; charset=UTF-8 
Allow: GET, POST 

<?xml version="1.0" encoding="utf-8"?> 
<products xmlns="urn:com.example.products" 
      xmlns:xl="http://www.w3.org/1999/xlink"> 
    <product id="1234" xl:type="simple" 
      xl:href="http://example.com/products/1234"> 
    <name>Red Stapler</name> 
    <price currency="EUR">3.14</price> 
    <availability>false</availability> 
    </product> 
</products>

y el JSON equivalente (más o menos):

HTTP/1.1 200 OK 
Content-Type: application/vnd.com.myservice.v2+json; charset=UTF-8 
Allow: GET, POST 

[ 
    { 
    id: "1234", 
    links: [ 
     { 
     rel: "self", 
     href: "http://example.com/products/1234" 
     } 
    ], 
    name: "Red Stapler", 
    price: { 
     currency: "EUR", 
     value: 3.14 
    }, 
    availability: false 
    } 
]

Fuente

2012-08-20 PatrikAkerstrand

+1 para el enlace a esa presentación si nada más. Gracias. –

Puede implementar versiones agregando una versión en el tipo de contenido :

application/vnd.acme.user-v1+xml

O también se puede utilizar un calificador en su cabecera Accept, de esa manera no se toca el tipo de contenido:

application/vnd.acme.user+xml;v=1

Se puede dividir el contenido de su tipo application/vnd.acme.user+xml en dos partes: la primera uno (application/vnd.acme.user) describe el tipo de medio y el segundo (xml) el formato de la respuesta. Eso significa que puede usar otro formato como json: application/vnd.acme.user+json.

En el mundo HATEOAS, XML es mejor que JSON para fines de legibilidad y semánticos, si desea utilizar JSON, podría interesarle esta especificación: https://github.com/kevinswiber/siren.

Fuente

2012-08-20 12:24:22

Gracias. Cuando se trata de decidir entre un calificador y un nuevo tipo de medio, ¿cuál preferiría para el control de versiones y por qué? – PatrikAkerstrand

Usaría el calificador para evitar modificar el tipo de contenido. Es solo una cuestión de gusto, supongo. –

La manera más limpia que conozco es mediante el uso de perfiles. Existe un IETF RFC para eso (RFC 6381).

Usando el encabezado accept, indique qué tipo de respuesta espera. Aún puedes usar calificadores también. Puede solicitar el cumplimiento de uno o más perfiles separados por comas, pero debe usar comillas si especifica más de un perfil.

Aceptar: application/json; perfiles = "" http://profiles.acme.com/user/v/1

Utilizando el encabezado de tipo de contenido, el servidor puede responder por igual:

Content-Type: application/json; profiles = "http://profiles.acme.com/user/v/1"

Fuente

2013-03-10 13:51:53 user2153885

de versiones de una API REST con XML y JSON Content-Type

Respuesta

Cuestiones relacionadas