¿Cuál es el beneficio de la conexión?

Question

¿Cuál es el beneficio de Connectedness tal como lo define la Arquitectura Orientada a Recursos (ROA)? De la forma en que lo entiendo, el quid de Connectedness es la capacidad de rastrear todo el estado de la aplicación utilizando solo los URI de raíz.

Pero, ¿qué tan útil es eso realmente?

Por ejemplo, imagine que HTTP GET http://example.com/users/joe devuelve un enlace a http://examples.com/uses/joe/bookmarks .

A menos que esté escribiendo un rastreador web tonto (y aún así me pregunto), todavía debe enseñar al cliente lo que significa cada enlace en tiempo de compilación. Es decir, el cliente debe saber que el " URI de marcadores " devuelve un URI a los recursos de Marcadores y luego pasa el control a algoritmos especiales de manejo de Marcadores. No puedes simplemente pasar enlaces a ciegas a algún método general del cliente. Ya que necesitas esta lógica de todos modos:

1. ¿Cuál es la diferencia entre que el cliente calcule el URI en tiempo de ejecución en lugar de proporcionarlo en tiempo de compilación? > http://example.com/users/bookmarks una URI raíz)?

2. ¿Por qué está enlazando utilizando http://example.com/users / joe / bookmarks / 2 preferido a id="2"?

El único beneficio que se me ocurre es la posibilidad de cambiar la ruta de los URI no root a lo largo del tiempo, pero esto rompe los enlaces almacenados en caché, por lo que no es realmente deseable. ¿Qué me estoy perdiendo?

Answer 1

Tienes razón en que cambiar Uris no es deseable, pero sucede y usar Uris completo en lugar de construirlos hace que sea más fácil lidiar con el cambio.

Otro beneficio es que su aplicación cliente puede recuperar fácilmente recursos de múltiples hosts. Si permitiera que su cliente construya los URI, el cliente debería saber en qué host residen ciertos recursos. Esto no es un gran problema cuando todos los recursos viven en un solo host, pero se vuelve más complicado cuando se agregan datos de varios hosts.

Mi último pensamiento es que quizás esté simplificando en exceso la noción de conexión observándola como una red estática de enlaces. Seguro que el cliente necesita saber acerca de la posible existencia de ciertos enlaces dentro de un recurso, pero no necesariamente tiene que saber exactamente cuáles son las consecuencias de seguir ese enlace.

Permítame darle un ejemplo: un usuario está haciendo un pedido de algunos artículos y está listo para enviar su carrito. El enlace de envío puede ir a dos lugares diferentes dependiendo de si el pedido se entregará local o internacionalmente. Tal vez los pedidos que superen cierto valor necesiten pasar por un paso adicional. El cliente solo sabe que tiene que seguir el enlace de envío, pero no tiene conocimiento compilado de dónde ir a continuación. Seguro que podrías construir un " siguiente paso " tipo de recurso para que el cliente pueda tener este conocimiento explícitamente, pero al hacer que el servidor entregue el enlace dinámicamente, se introduce mucho menos acoplamiento cliente-servidor.

Pienso en los enlaces en los recursos como marcadores de posición para lo que el usuario podría elegir hacer. Quien hará el trabajo y cómo se hará estará determinado por la uri que el servidor adjunta a ese enlace.

Answer 2

Es más fácil de ampliar, y podría escribir pequeñas aplicaciones y scripts para que funcionen junto con la aplicación principal con bastante facilidad.

Añadido: Bueno, todo el punto comienza con la idea de que no especifica en tiempo de compilación cómo convertir los URI a UID de forma codificada, en lugar de eso, puede usar diccionarios o análisis para hacer eso, lo que le brinda mucho más. sistema flexible.

Luego, más adelante, diga que otra persona decide cambiar la sintaxis de URI, esa persona podría escribir un pequeño script que traduzca URI sin tocar su aplicación principal. Otra ventaja es que si sus URI son usuarios lógicos, otros, incluso en un escenario corporativo, pueden escribir fácilmente mashups para hacer uso de su sistema, sin tocar su aplicación original o incluso recompilarla.

Por supuesto, el lado contrario a todo el argumento es que le llevará más tiempo implementar un sistema basado en URI sobre un sistema UID simple. Pero si otras personas utilizarán su aplicación de manera regular, esa inversión inicial tendrá un gran retorno (se podría decir que tiene un buen retorno de la inversión basado en la extensibilidad).

Añadido: Y otro punto que es, hasta cierto punto, un asunto de gustos, es que el URI en sí será un Nombre mejor, ya que transmite un significado lógico y definido

Answer 3

Agregaré mi propia respuesta:

1. Es mucho más fácil seguir las URI proporcionadas por el servidor que construirlas tú mismo. Esto es especialmente cierto ya que las relaciones de recursos se vuelven demasiado complejas para ser expresadas en reglas simples. Es más fácil codificar la lógica una vez en el servidor que volver a implementarla en numerosos clientes.
2. La relación entre los recursos puede cambiar incluso si los URI de recursos individuales permanecen sin cambios. Por ejemplo, imagine que Google Maps indexa sus mosaicos de mapas de 0 a 100, contando desde la parte superior izquierda hasta la parte inferior derecha de la pantalla. Si Google Maps cambiara la escala de sus mosaicos, los clientes que calculen los índices relativos de mosaicos se romperían.
3. Las ID personalizadas identifican un recurso. Los URI van un paso más allá al identificar cómo recuperar la representación de recursos. Esto simplifica la lógica de los clientes de solo lectura, como los rastreadores web o los clientes que descargan recursos opacos, como archivos de audio o video.