¿HATEOAS implica que las cadenas de consulta no son RESTful?

Question

¿La recomendación HATEOAS (hipermedio como motor de la aplicación) implica que las cadenas de consulta no son RESTful?

Editar: Se sugirió a continuación que las cadenas de consulta pueden no tener mucho que ver con el estado y que, por lo tanto, la pregunta es desconcertante. Sugeriría que no tiene sentido que el URI tenga una cadena de consulta a menos que el cliente esté completando argumentos. Si el cliente está llenando argumentos, está adulterando el URI proporcionado por el servidor y me pregunto si esto viola el principio REST.

Editar 2: me doy cuenta de que la cadena de consulta parece inofensiva si el cliente la trata como opaca (y la cadena de consulta puede ser un legado y por lo tanto conveniente). Sin embargo, en una de las respuestas a continuación, Roy Fielding es citado diciendo que el URI debe tomarse como transparente. Si es transparente, entonces creo que se fomenta la adulteración y eso parece diluir el principio HATEOAS. ¿Esa dilución sigue siendo coherente con HATEOAS? Esto plantea la pregunta de si REST está pidiendo el estrecho acoplamiento que parece ser la construcción de URI.

Actualización En este tutorial de REST http://rest.elkstein.org/ se sugiere que la construcción de URI tenga un diseño incorrecto y no sea RESTful. También itera lo que dijo @zoul en la respuesta aceptada.

Por ejemplo, una solicitud de "lista de productos" podría devolver una identificación por producto, y la especificación dice que debe usar http://www.acme.com/product/PRODUCT_ID para obtener detalles adicionales. Eso es un mal diseño. Por el contrario, la respuesta debe incluir la URL real con cada elemento: http://www.acme.com/product/001263, etc. Sí, esto significa que la salida es más grande. Pero también significa que puede dirigir fácilmente a los clientes a nuevas URL según sea necesario

Si un humano está mirando esta lista y no quiere lo que puede ver, puede haber "10 elementos anteriores" y sin embargo, si no hay un programa humano, sino un programa cliente, este aspecto de REST parece un poco extraño debido a todos los "http://www" que el programa cliente puede no tener utilidad.

Answer 1

yo sugeriría que no tiene sentido para la URI tiene una cadena de consulta menos que el cliente eran abundantes en argumentos.

Eso no me parece cierto. Si le preguntas servidor para un puñado de fotos, es perfectamente válida para el servidor devuelva algo como esto:

<photos> 
    <photo url="http://somewhere/photo?id=1"/> 
    <photo url="http://somewhere/photo?id=2"/> 
</photos> 

usted podría utilizar /photo/id/xx ruta vez, pero ese no es el punto. Estas URL se pueden usar incluso sin que el cliente las cambie. En cuanto a su segundo punto:

Si el cliente está llenando argumentos entonces se adulterando la URI especificado en servidor y me pregunto si esto viola el principio de descanso.

Creo que este es el corazón de su pregunta. Y No creo que haya que tratar a las direcciones URL como identificadores opacos, ver this quote por Roy Fielding mismo:

RESTO no requiere que sea un URI opaco. El único lugar donde aparece la palabra opaco en mi disertación es donde me quejo de la opacidad de las cookies. De hecho, REST aplicaciones son, en todo momento, anima a utilizar humana significativa, identificadores jerárquicos con el fin de maximizar el uso casual de la información más allá de lo que se prevé por la aplicación original.

Answer 2

No veo qué cadenas de consulta tienen que ver con el seguimiento de estado. El objetivo del principio HATEOAS es abstenerse de rastrear el estado en el cliente, desde "hacer trampa" hasta ir a URL "conocidas" para obtener datos. Si esas URL tienen cadenas de consulta o no me parece irrelevante.

Oh. ¿Tal vez le interesan las URL de búsqueda en las que una determinada parte de la URL debe cambiar según los criterios de búsqueda? Debido a que tales URL aparentemente tendrían que conocerse de antemano, representando así la información fuera de banda que buscamos eliminar con REST? Creo que esto se puede resolver usando plantillas de URL. Ejemplo:

client -> server 
    GET /items 
server -> client 
    /* …whatever, an item index… */ 
    <search by="color">http://somewhere/items/colored/{#color_id}</search> 

De esta manera no es necesario ningún conocimiento a priori URL para buscar y usted debe ser fiel al principio de seguimiento del estado de hipermedia. Pero mi comprensión de REST es muy débil, estoy respondiendo principalmente para ordenar las cosas en mi cabeza y obtener retroalimentación. Seguramente hay una mejor respuesta.

Answer 3

No HATEOAS no significa que las cadenas de consulta no son RESTful. De hecho, exactamente lo contrario puede ser el caso.

Tenga en cuenta el escenario de inicio de sesión común donde el usuario intenta acceder a un recurso seguro y se envían a una pantalla de inicio de sesión. La URL de la pantalla de inicio de sesión a menudo contiene un parámetro de cadena de consulta llamado redirectUrl, que le dice a la pantalla de inicio de sesión a dónde volver después de un inicio de sesión exitoso. Este es un ejemplo del uso de URI para mantener el estado del cliente.

Aquí hay otro ejemplo de almacenamiento del estado del cliente en la URL: http://yuml.me/diagram/scruffy/class/[Company] <> -1> [Ubicación], [Ubicación] + -> [Punto ]

Answer 4

Mi opinión es que REST por sí mismo no dice nada sobre si el URI es opaco o transparente, pero esa aplicación REST no debe depender del cliente para construir URI que el servidor todavía no haya mencionado. Hay una variedad de maneras para que el servidor haga esto: por ejemplo, una colección que puede incluir enlaces a sus miembros, o un formulario HTML con el método GET obviamente causará que un URI con params se cree y se obtenga del lado del cliente, o hay al menos un par de estándares propuestos para plantillas de URI. Lo importante para REST es que la descripción del URI válido debe definirse de alguna manera por el servidor en las respuestas que le da a los clientes, y no en alguna documentación de API fuera de banda

La transparencia del URI es algo bueno en el de la misma manera que la transparencia en cualquier lugar es algo bueno, promueve y permite usos novedosos y no planificados de recursos más allá de lo que el diseñador había imaginado originalmente, pero (al menos a mi entender) buenos URIs no son necesarios para describir una interfaz como RESTful

Answer 5

en Roy Fielding own words (cuarta viñeta en el artículo):

Una API REST no debe definir nombres de recursos fijos o jerarquías (un acoplamiento obvio de cliente y servidor).Los servidores deben tener la libertad de controlar su propio espacio de nombres. En su lugar, permite a los servidores instruir a los clientes sobre cómo construir URIs apropiados, como se hace en formularios HTML y plantillas URI, al definir esas instrucciones en tipos de medios y relaciones de enlaces.

En otras palabras, siempre que los clientes no obtengan las piezas que necesitan para generar URI en la información fuera de banda, HATEAOS no se infringe.

---

Tenga en cuenta que plantillas URI pueden ser usados ​​en URIs sin cadenas de consulta así:

http://example.com/dictionary/{term} 

Así que la pregunta es más acerca de si se trata de REST para permitir que el cliente para construir URLs que si es RESTful utilizar cadenas de consulta.

Observe cómo la cantidad de información servida al cliente en el ejemplo anterior es exactamente equivalente a para servir una lista exhaustiva de todos los términos posibles, pero es mucho más eficiente desde el punto de vista del ancho de banda.

También permite al cliente buscar en el diccionario respetando HATEAOS, lo que sería imposible sin las instrucciones dentro de la banda. Estoy bastante seguro de que Roy Fielding no está promoviendo un sitio Web sin ningún tipo de función de búsqueda ...

---

Acerca de su tercer comentario, creo que Roy Fielding está animando a los diseñadores API tener URI "transparentes" como una característica adicional encima de HATEAOS. No interpreto su cita en la respuesta de zoul como una afirmación de que los clientes usarían "sentido común" para navegar una API con URI claros. Todavía usarían instrucciones dentro de banda (como formularios y plantillas de URI). Pero esto no significa que los URI transparentes no sean mucho mejores que los URI oscuros, sorprendentes y opacos.

De hecho, los URI transparentes proporcionan un valor añadido a una API (la depuración es un caso de uso en el que puedo pensar que tener URI transparentes es invaluable).

---

Para obtener más información sobre URI templates, puede echar un vistazo a RFC6570.

Answer 6

Para seguir con lo que ha dicho Darrel, no necesita modificar la URL para incluir una segunda URL.

Para la autenticación basada en cookies, puede devolver el formulario de inicio de sesión dentro del cuerpo de la respuesta 401, con una acción de formulario vacía, y usar nombres de campo únicos que POSTed ay procesados ​​por cada recurso. De esa forma evitará la necesidad de una redirección completa. Si no puede tener todas las solicitudes de inicio de sesión del proceso de recursos, puede hacer que el 401 form action point apunte a un recurso de acción y coloque la URL de redireccionamiento en un campo oculto. De cualquier forma, evitará tener una URL-en-una URL fea, y la primera forma evita la necesidad tanto de una acción de inicio de sesión de RPC como de una redirección, manteniendo toda la interacción enfocada en el recurso.