REST - Compensaciones entre la negociación de contenido mediante el encabezado Aceptar frente a las extensiones

Esto, "Sin embargo, filosóficamente, el primer enfoque es el único enfoque", y este "El enfoque oficial correcto de REST es utilizar 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) ...

"sección 6.2.1 no dice que la negociación de contenido debería ser utilizado todo el tiempo. " cite

Esa conversación en particular se encuentra en el contexto del encabezado "Aceptar lenguaje:", pero lo mismo se aplica igualmente al encabezado "Aceptar:", como se explica 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

enlace

que apuntan a las dos ediciones en PDF ".

Lo que quiere decir con esto es que no hay problema en utilizar 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 sobre las virtudes de usar parámetros de consulta en lugar de usar extensiones de archivo para diferentes tipos de medios ...

"Es por eso que siempre prefiero las extensiones. Ninguna de las opciones tiene nada que ver con REST. " cite

Nuevamente, eso es ligeramente diferente a las extensiones de Aceptar frente a las de nombre de archivo, pero la postura 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.

El enfoque oficial correcto de RESTful es usar el encabezado Accept: .

Sin embargo, debe tener cuidado de no romper el almacenamiento en caché, que es uno de los requisitos de REST. Debe tener el encabezado y el caché Vary: Accept que lo entienden. En el mundo ideal lo tendrías, pero en la vida real tu millage puede variar. Así que la segunda solución no es tan limpia, pero podría ser más práctica.

También, tenga en cuenta que algunos navegadores muy antiguos solían ignorar los encabezados, confiando en la extensión.

Técnicamente, en realidad no importa, su servidor web podrá pasar el proceso de manera apropiada como se ve. (Supongo que esto pero no parece un showstopper).

Sin embargo, filosóficamente, el primer enfoque es el único. 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 en 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 hay algo que permita el transporte), pero ese método no se convierte en descripción del objeto . De la misma manera, los aspectos del valor de retorno no es el URI. El objeto sigue siendo algo y no something.xml o something.json

Supongamos que si no quieres usar el encabezado Aceptar, pero si todavía quieres ser realmente RESTO filosóficamente, no me importa algo como:

GET /api/something?parm1=value1&return_type=xml

a diferencia de

GET /api/something.xml?parm1=value1 (or /api/something.json?param1=value1)

Pero como dije, esta diferencia es solo filosófica.

@vartec: Creo que estás equivocado

El principio oficial correcto de RESTful dice que no se debe ocultar nada en los encabezados HTTP, ya que es el URI que está expuesto o al que se hace referencia, cualquier detalle sobre la solicitud / respuesta debe proporcionarse como parte del URI

Por lo tanto, recomiendo encarecidamente evitar el uso del encabezado para los detalles que tratan sobre la solicitud & respuesta, y se adhieren a

 GET /api/something.xml?parm1=value1 (or /api/something.json?param1=value1)

No puedo encontrar las referencias rápidamente, pero las publicaré con ellas (en realidad, puede consultar el libro de publicación de O'reilly "Servicios web RESTful" ( enlace ) que confirma lo mismo