rest - ventajas - HATEOAS: ¿URLs absolutas o relativas?

ventajas de hateoas (8)

Al diseñar un servicio web RESTful utilizando HATEOAS, ¿cuáles son los pros y los contras de mostrar un enlace como una URL completa (" http://server:port/application/customers/1234 ") frente a la ruta ("/ application / clientes / 1234 ")?

A medida que su aplicación se amplía, es posible que desee equilibrar la carga, conmutar por error, etc. Si devuelve URI absolutos, las aplicaciones del lado del cliente seguirán la configuración de servidores en evolución.

Depende de quién escriba el código del cliente. Si está escribiendo el cliente y el servidor, entonces no hace mucha diferencia. O bien sufrirá el dolor de construir las URL en el cliente o en el servidor.

Sin embargo, si está creando el servidor y espera que otras personas escriban código de cliente, entonces le amarán mucho más si proporciona URI completos. La resolución de URI relativos puede ser un poco complicado. Primero, cómo los resuelva depende del tipo de medio devuelto. Html tiene la etiqueta base, Xml puede tener etiquetas xml: base en cada elemento anidado, las fuentes Atom podrían tener una base en el feed y una base diferente en el contenido. Si no le proporciona a su cliente información explícita sobre el URI base, entonces tiene que obtener el URI base del URI de solicitud, ¡o tal vez del encabezado Content-Location! Y ten cuidado con esa barra final. El URI base se determina ignorando todos los caracteres a la derecha de la última barra inclinada. Esto significa que la barra inclinada final es ahora muy significativa cuando se resuelven los URI relativos.

El único otro problema que requiere una pequeña mención es el tamaño del documento. Si devuelve una gran lista de elementos donde cada elemento puede tener enlaces múltiples, el uso de URL absolutas puede agregar una cantidad significativa de bytes a su entidad si no comprime la entidad. Este es un problema de rendimiento y debe decidir si es significativo caso por caso.

Existe una sutil ambigüedad conceptual cuando las personas dicen "relativo uri".

Según la definición de RFC3986 , un uri genérico contiene:

URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] hier-part = "//" authority path-abempty / path-absolute / path-rootless / path-empty foo://example.com:8042/over/there?name=ferret#nose /_/ /______________//_________/ /_________/ /__/ | | | | | scheme authority path query fragment

Lo difícil es que cuando se omiten el esquema y la autoridad, la parte "ruta" en sí misma puede ser una ruta absoluta (comienza con "/") o una ruta relativa "sin raíz". Ejemplos:

Un uri absoluto o un uri completo: "http://example.com:8042/over/there?name=ferret"
Y este es un uri relativo, con ruta absoluta : "/ over / there"
Y esta es una uri relativa, con una ruta relativa : "aquí" o "./aquí" o "../aquí", etc.

Por lo tanto, si la pregunta era "si un servidor debe producir una ruta relativa en una respuesta tranquila", la respuesta es "No" y la razón detallada está disponible aquí . Creo que la mayoría de las personas (incluyéndome a mí) en contra de "relativo uri" están en realidad en contra de "camino relativo".

Y en la práctica, la mayor parte del marco MVC del lado del servidor puede generar fácilmente uri relativo con ruta absoluta como "/ absolute / path / to / the / controller", y la pregunta es "si la implementación del servidor debe prefijar un esquema: // hostname : puerto frente a la ruta absoluta ". Como la pregunta del OP. No estoy seguro de esto.

Por un lado, todavía creo que se recomienda que el servidor devuelva un uri completo. Sin embargo, el servidor nunca debe codificar el nombre de host: cosa del puerto dentro del código fuente como este (de lo contrario, preferiría recurrir a la URL relativa con ruta absoluta). La solución es del lado del servidor siempre obteniendo ese prefijo del encabezado "Host" de la solicitud HTTP. Sin embargo, no estoy seguro de si esto funciona para todas las situaciones.

Por otro lado, parece no ser muy problemático para el cliente concatenar el "http://example.com:8042" y la ruta absoluta. Después de todo, el cliente ya conoce ese esquema y nombre de dominio cuando envía la solicitud al servidor ¿verdad?

Con todo, yo diría que recomiendo usar uri absoluto, posiblemente retroceso a uri relativo con ruta absoluta, nunca usar ruta relativa .

La única diferencia real parece ser que es más fácil para los clientes si consumen URI absolutos en lugar de tener que construirlos a partir de la versión relativa. Por supuesto, esa diferencia sería suficiente para convencerme de hacer la versión absoluta.

Siempre debes usar la URL completa. Actúa como el identificador único del recurso, ya que todas las URL deben ser únicas.

También diría que debes ser coherente. Dado que el encabezado HTTP de ubicación espera una URL completa basada en la especificación HTTP, la URL completa se envía de regreso en el encabezado Ubicación al cliente cuando se crea un nuevo recurso. Sería extraño que proporcione una URL completa en el encabezado Ubicación y luego URI relativos en los enlaces dentro de su cuerpo de respuesta.

Una consideración importante en los resultados de API grandes es la sobrecarga de red adicional de incluir el URI completo repetidamente. Créalo o no, gzip no resuelve completamente este problema (no estoy seguro de por qué). Nos sorprendió la cantidad de espacio que ocupaba el URI completo cuando se incluyeron cientos de enlaces en un resultado.

Usando la tricotomía de RayLou, mi organización optó por favorecer (2). La razón principal es evitar los ataques XSS (Cross-Site Scripting). El problema es que si un atacante puede inyectar su propia raíz URL en la respuesta que recibe del servidor, las solicitudes posteriores de los usuarios (como una solicitud de autenticación con nombre de usuario y contraseña) pueden reenviarse al propio servidor del atacante *.

Algunos han planteado la cuestión de poder redirigir las solicitudes a otros servidores para el equilibrio de carga, pero (aunque esa no es mi área de especialización) apostaría a que hay mejores formas de habilitar el equilibrio de carga sin tener que redirigir explícitamente a los clientes a diferentes Hospedadores.

* por favor avíseme si hay algún defecto en esta línea de razonamiento. El objetivo, por supuesto, no es prevenir todos los ataques, sino al menos una vía de ataque.

~~Una desventaja del uso de URI absolutos es que la API no puede ser procesada.~~

Tómalo de vuelta ... no es cierto. Deberías buscar una URL completa que incluya el dominio.