Ley de Demeter vs. REST

Question

La Ley de Demeter (realmente debería ser una sugerencia de Demeter) dice que no debe "acercarse" a un objeto para alcanzar sus objetos secundarios. Si usted, como cliente, necesita realizar alguna operación no trivial, la mayoría de las veces el modelo de dominio con el que está trabajando debe soportar esa operación.

REST es en principio una jerarquía tonta de objetos. Es como un sistema de archivos de recursos/objetos, donde cada objeto podría tener objetos secundarios. Casi siempre logras llegar con REST. Opcionalmente, puede crear tipos de objetos compuestos por convención usando técnicas REST, y siempre que el proveedor y el cliente acuerden operaciones de nivel superior, puede evitar el alcance.

Entonces, ¿cómo balanceas REST y Demeter? Me parece que no están en conflicto, porque REST se trata de un acoplamiento súper flexible hasta el punto en que no tiene sentido que el proveedor intente anticipar todas las necesidades de los clientes, mientras que Demeter supone que la lógica puede migrar a su lugar más natural a través de la refactorización.

Sin embargo, podría argumentar que REST es solo un intervalo hasta que comprenda mejor a sus clientes. ¿REST es solo un truco? ¿Es Demeter poco realista en cualquier escenario de servidor/cliente?

Answer 1

• ¿Es Demeter poco realista en cualquier escenario de servidor/cliente?

Creo que respondió su propia pregunta aquí. ¿Cómo es REST de esta manera diferente a SOAP o XML-RPC en este sentido?

El punto de REST no es proporcionar acoplamiento super-suelta, pero el siguiente:

• proporcionar un identificador que describe con precisión que se solicitó el recurso.
• proporcionar servicios que se comporta como se esperaba GET solicitudes son idempotente, PUT actualiza los registros, POST crea, DELETE elimina
• Minimizar estado se almacenan en el servidor
• Derribar una complejidad innecesaria

hay casos donde REST no es la mejor respuesta, pero REST funciona notablemente bien en general.

Answer 2

Pago esa ley/sugerencia sin importar en absoluto. Derrota la mitad del beneficio de la agregación y la composición, y no lo tendré.

Answer 3

Creo que son realmente ortogonales. REST describe una colección de recursos abordados por URI con un conjunto de métodos canónicos: GET, POST, etc. Si la rutina REST devuelve un URI, eso no está "llegando", sino que identifica un objeto diferente con los mismos nombres de método.

Answer 4

Un enlace que es proporcionado por una representación, expuesto por una interfaz RESTful, puede ser completamente opaco sin violar ninguna de las restricciones de REST. Por lo tanto, sugeriría que REST es completamente consistente con la Ley de Demeter. No es necesario que el enlace exponga la estructura del espacio de URL en su URL.

p. Ej. en un escenario orientado a objetos, puede reemplazar la llamada a.b.c con a.bc

En una representación REST que podría crear el siguiente:

<a> 
    <link href="bc"/> 
</a> 

en lugar de hacer

GET a 

    <a> 
     <link href="b"/> 
    </a> 

GET b 

    <b> 
     <link href="c"/> 
    </b> 

GET c 

Me habría de acuerdo con altCognito y decir que uno de los principales objetivos del resto es bajo acoplamiento. La interfaz uniforme, los tipos de medios estándar y HATEOAS se combinan para producir una interfaz extremadamente débilmente acoplada.

En respuesta al comentario de David:

resto es todo acerca de acoplamiento súper suelta hasta el punto en que no tiene sentido para el proveedor para tratar de prever todas las necesidades de los clientes

En realidad, REST se trata de limitar las opciones de los clientes al proporcionar solo enlaces válidos en las representaciones. Dentro de esas restricciones, el cliente puede intentar satisfacer sus propias necesidades. Al eliminar el conocimiento del cliente sobre cuándo se pueden realizar ciertas solicitudes, se logra un acoplamiento flexible. El acoplamiento flojo no se logra al enumerar un conjunto de recursos y decir "ok, puede obtener, poner, publicar, eliminar todo lo que desee".