Estoy trabajando en el diseño de una API RESTful. Sabemos que queremos devolver JSON y XML para cualquier recurso dado. Había estado pensando que haríamos algo como esto:
GET /api/something?param1=value1
Accept: application/xml (or application/json)
Sin embargo, alguien rechazó el uso de extensiones para esto, así:
GET /api/something.xml?parm1=value1 (or /api/something.json?param1=value1)
¿Cuáles son las compensaciones con estos enfoques? ¿Es mejor confiar en el encabezado aceptar cuando no se especifica una extensión, pero honrar las extensiones cuando se especifica? ¿Hay algún inconveniente en ese enfoque?
architecture
web-services
rest
http
Brandon Linton
fuente
fuente
Respuestas:
Esto, "Sin embargo, filosóficamente, el primer enfoque es el único enfoque", y este "El enfoque RESTful oficial adecuado es usar Aceptar: encabezado". son ampliamente percibidos como el caso, pero también son absolutamente incorrectos .
Aquí hay un breve fragmento de Roy Fielding (quien definió REST) ...
"la sección 6.2.1 no dice que la negociación de contenido debe usarse todo el tiempo". citar
Esa conversación particular está en el contexto del encabezado 'Accept-Language:', pero lo mismo se aplica igualmente al encabezado 'Accept:', como se aclara más adelante en su respuesta ...
"No tengo idea de por qué la gente no puede ver el segundo y tercer enlace en la página superior
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
ese punto a las dos ediciones en PDF ".
Lo que quiere decir es que no hay problema al usar diferentes puntos finales para diferentes representaciones de los mismos datos de origen. (En este caso, un punto final .html y dos puntos finales .pdf diferentes).
También en una discusión similar, esta vez con respecto a las virtudes del uso de parámetros de consulta versus el uso de extensiones de archivo para diferentes tipos de medios ...
"Es por eso que siempre prefiero las extensiones. Ninguna opción tiene nada que ver con REST". citar
Una vez más, eso es ligeramente diferente a Aceptar frente a extensiones de nombre de archivo, pero la posición de Fielding aún es clara.
Respuesta: realmente no importa mucho. Las compensaciones entre los dos no son muy significativas y ambos son estilos aceptables.
fuente
El enfoque RESTful oficial adecuado es usar el
Accept:encabezado.Sin embargo, debe tener cuidado de no romper la capacidad de almacenamiento en caché, que es uno de los requisitos de REST. Necesita tener
Vary: Acceptencabezado y caché que lo entienda. En el mundo ideal lo tendrías, pero en la vida real tu millaje puede variar. Entonces, la segunda solución no es tan limpia, pero podría ser más práctica.Además, tenga en cuenta que algunos navegadores muy antiguos solían ignorar los encabezados, confiando en su lugar en la extensión.
fuente
Técnicamente, en realidad no importa: su servidor web podrá pasar el proceso adecuadamente como parece. (Asumo esto pero no parece un showtopper).
Sin embargo, filosóficamente: el primer enfoque es el único enfoque. En REST, la URL en realidad solo apunta a un URI, que es solo un recurso. Piense por un momento en este recurso igual que el objeto en la programación orientada a objetos. Usted habla con este recurso a través de solo 4 métodos (también conocido como GET / POST / PUT / DELETE, o si algo lo permite el transporte), pero ese método no se convierte en la descripción del objeto. Del mismo modo, los aspectos del valor de retorno no son el URI. El objeto sigue siendo algo y no algo.xml o algo.json
Suponga que si no desea usar el encabezado Aceptar, pero si todavía quiere estar verdaderamente DESCANSO filosóficamente, no me importaría algo como:
Opuesto a
Pero como dije, esta diferencia es solo filosófica.
fuente
@vartec: creo que te equivocas
El principio RESTful oficial apropiado dice que nada debe estar oculto en los encabezados HTTP, ya que es el URI el que está expuesto o referenciado, cualquier detalle sobre la solicitud / respuesta debe proporcionarse como parte del URI
Por lo tanto, recomiendo evitar usar el encabezado para obtener detalles sobre la solicitud y la respuesta, y seguir con
No puedo encontrar las referencias rápidamente, pero las volveré a publicar (en realidad, puede consultar el libro de publicación de O'reilly "Servicios web RESTful" ( http://shop.oreilly.com/product/9780596529260.do ) que confirma lo mismo
fuente