REST y múltiples formatos de datos

Question

Ok, aquí está el hecho. StackOverflow está implementado al estilo REST. Cuando visitas una pregunta/$ id/URL específica, puedes ver la pregunta. El contenido se devuelve en HTML porque es lo que entiende el navegador.

Tengo que desarrollar mi propio servicio REST. El hecho es que tengo que devolver múltiples formatos para la misma información. Por ejemplo, el valor predeterminado podría ser HTML, pero podría devolver también un XML o un JSON.

Pregunta es: ¿cuál es el estilo recomendado para lograrlo? Tres opciones (más de sus sugerencias votos)

1. opción en la URL (por ejemplo http://example.com/questions/12345/?format=json)
2. interfaz diferente (por ejemplo: para los datos JSON tiene http://example.com/questions/1234/json/ o http://example.com/json/questions/12345/, para los datos XML que tiene http://example.com/questions/1234/xml/ etc ... usted consigue el punto) cabecea
3. HTTP Accept: application/json

lo mismo es para las operaciones put (POST). Si deseo enviar datos en diferentes formatos, debo informar al receptor el formato que estoy proporcionando, por lo que se cumple la misma situación (y pregunta).

Gracias!

Editar: propuesta adicional es la siguiente

4) especificar una URL apropiada para cada formato, por ejemplo, http://example.com/questions/12345.json. Esto se ve bien, pero ¿no significaría esto que, por coherencia, también deberíamos tener http://example.com/questions/12345.html? suena tan 1995 ... :)

PD: Odio el descuento poniendo una orden arbitraria a la lista. Si quiero comenzar con 4, debería ser capaz de hacerlo.

Answer 1

Iría por Opción 1 (parámetro URL) ya que es la más consistente con los principios de REST, y la más pragmática.

La opción 2 huele mal: está hablando de diferentes representaciones del mismo recurso, por lo que debe usar el mismo URI para ellas.

La opción 3 suena a demasiado difícil de controlar, ¿cómo la probaría manualmente desde su navegador, por ejemplo?

(Los mismos argumentos se aplican para PUT/POST.)

Answer 2

No importa en lo más mínimo entre 1. y 2. Un URI es opaco, por lo que desde la parte de interfaz resto de ella, no hay diferencia.

Desde una perspectiva de almacenamiento en caché, 1. evitará que muchas memorias caché hagan su trabajo.

3. está bien si quieres hacer conneg contra múltiples represetos.

Por lo general, las personas utilizan conexión con el encabezado Aceptar, posiblemente con una redirección al URI totalmente calificado utilizando/customer/21.json

Answer 3

La opción n. ° 3, configurando el encabezado HTTP "Aceptar", está más en consonancia con la especificación HTTP y, entre los puristas de REST, se considera la más correcta. También significa que mantiene la misma URL (recurso) sin importar cuál es la representación.

Puede encontrar agentes de usuario que no son capaces de configurar un encabezado Accept, por lo que es recomendable admitir un mecanismo de copia de seguridad para especificar el formato de respuesta. En ese caso, sugiero un parámetro de cadena de consulta URL. El uso de un parámetro de cadena de consulta de URL significa que mantiene la misma URL central, sin importar el tipo de contenido devuelto. Esto deja en claro que los clientes solo deben emitir un PUT a esa URL y no a las /foo/bar.json o las /foo/bar.xml URLs.

Editar: Otra cosa a considerar si decide ir con el sufijo de URL (es decir, foo.json vs. foo? Format = json) es que puede tener problemas con los proxies de almacenamiento en caché. Si alguien envía un PUT a /foo.json, un proxy no lo interpretará como una solicitud para invalidar /foo.xml. Sin embargo, si usa/foo? Format = json, todo se almacena bajo el mismo recurso (/ foo) en el proxy.