que - rest y restful

Tipo de contenido REST: ¿Debe basarse en la extensión o en el encabezado Aceptar? (7)

Ambos son validos Cita de xml.com :

Un recurso puede tener más de una representación. Hay cuatro formas frecuentemente utilizadas de entregar la representación de recursos correcta a los consumidores:
Negociación dirigida por el servidor. El proveedor del servicio determina la representación correcta del conocimiento previo de sus clientes o utiliza la información provista en los encabezados HTTP como Aceptar, Aceptar conjunto de caracteres, Aceptar codificación, Aceptar idioma y Usuario-Agente. El inconveniente de este enfoque es que el servidor puede no tener el mejor conocimiento sobre lo que realmente quiere un cliente.
Negociación dirigida por el cliente. Un cliente inicia una solicitud a un servidor. El servidor devuelve una lista de representaciones disponibles. El cliente luego selecciona la representación que quiere y envía una segunda solicitud al servidor. El inconveniente es que un cliente necesita enviar dos solicitudes.
Negociación impulsada por proxy. Un cliente inicia una solicitud a un servidor a través de un proxy. El proxy pasa la solicitud al servidor y obtiene una lista de representaciones. El proxy selecciona una representación según las preferencias establecidas por el cliente y devuelve la representación al cliente.
Representación especificada por URI. Un cliente especifica la representación que quiere en la cadena de consulta de URI.

¿Debería la representación (html, xml, json) devuelta por un servicio web RESTful ser determinada por la url o por el encabezado Aceptar de HTTP?

Consulte el Capítulo 5 - Transferencia de estado representacional (REST) , sección 5.2.1.2 Representaciones de la dissertation de Roy Fielding sobre estilos arquitectónicos:

El formato de datos de una representación se conoce como tipo de medios [48] .

Al mirar el enlace, vemos que se refiere a MIME. Así que supongo que en el lenguaje HTTP, se representa con un encabezado Content-Type para POST / PUT y el encabezado Accept para GET.

Aquí está el resto del párrafo (para completarlo):

Una representación puede ser incluida en un mensaje y procesada por el destinatario de acuerdo con los datos de control del mensaje y la naturaleza del tipo de medio. Algunos tipos de medios están destinados al procesamiento automatizado, algunos están destinados a ser visualizados por un usuario, y algunos son capaces de ambos. Los tipos de medios compuestos se pueden usar para encerrar múltiples representaciones en un solo mensaje.

PD: No estoy seguro de por qué la gente nunca mira en el lugar donde realmente se define REST ...

Dado que muchas URL RESTful no tienen una extensión, debe / debe basarse en Content-Type

editar: no me refiero a que suene tan duro como lo hace, más que a que tenga que prestar atención al tipo de contenido y no siempre podrá referirse a la extensión

Dado que usted menciona un servicio web RESTful y no cualquier servicio web, me inclino por lo que respalda el estándar subyacente: HTTP 1.1 y su negociación de contenido que se basa en Accept encabezado HTTP.

Como expliqué en mi respuesta a ¿Puedo cambiar los encabezados de la solicitud HTTP enviada por el navegador , la dirección (URI) y la representación son dos pilares distintos de un diseño RESTful y no es necesario mezclarlos. No se debe abusar de URI para incrustar representaciones aceptables cuando hay un encabezado Accept .

Solo si su aplicación web se puede ejecutar y utilizar potencialmente en un entorno donde el filtrado de encabezado HTTP está involucrado en nodos intermedios, entonces debe admitir la negociación de contenido basado en URI. A decir verdad, tales proxies intrusivos o que funcionan incorrectamente deberían ser reemplazados si es posible y factible.

¡Aclamaciones!
Shonzilla

Esto no es cuestion

Aceptar depende de conneg (negociación de contenido). Conneg permitirá que el cliente decida qué tipo de medio aceptan a través del encabezado Aceptar. La respuesta estará en ese formato, junto con un encabezado Vary: Accept.

Por otro lado, también es posible y perfectamente válido exponer su recurso como /resource.json y /resource.xml.

Lo ideal es implementar tanto: / resource (uri genérico que admita conneg) /resource.xml /resource.json

la versión conectada devuelta por / resource puede simplemente redireccionar al uri correcto según el tipo de medio negociado. De forma alternativa, se puede devolver la representación correcta desde el uri genérico y usar Content-Location para especificar la representación específica que se devolvió.

Hay problemas con el uso del tipo de contenido ... Discutí esto en mi blog http://shouldersofgiants.co.uk/Blog y finalmente decidí incluir la representación en el URI como se sugiere en RESTful Web Services por Richardson y Ruby.

Utilice el encabezado Aceptar, si se proporciona, URI como failover.