Law of Demeter vs. REST

Question

The Law of Demeter (really should be the suggestion of Demeter) says that you shouldn't "reach through" an object to get at their child objects. If you, as a client, need to perform some non-trivial operation, most of the time the domain model you're working with should support that operation.

REST is in principle a dumb hierarchy of objects. It is like a filesystem of resources/objects, where each object could have child objects. You almost always reach through with REST. You can optionally build up by-convention composite object types using REST techniques, and as long as the provider and the client agree on higher-level operations, you can avoid the reach-through.

So, how do you balance REST and Demeter? It seems to me that they are not in conflict, because REST is all about super-loose coupling to the point where it is pointless for the provider to try to anticipate all the needs of the clients, whereas Demeter assumes that logic can migrate to its most natural place through refactoring.

However, you could argue that REST is just a stop-gap until you understand your clients better. Is REST just a hack? Is Demeter unrealistic in any server/client scenario?

Answer 1

• Is Demeter unrealistic in any server/client scenario?

I think you answered your own question here. How is REST in this manner different than SOAP or XML-RPC in this regard?

The point of REST is not to provide super-loose coupling, but the following:

• Provide a identifier which accurately describes the resource being requested.
• Provide services which behave as expected GET requests are Idempotent, POST updates records, PUT creates, DELETE deletes
• Minimize state being stored on the server
• Tear down unnecessary complexity

There are cases where REST isn't the best answer, but REST works remarkably well in general.

Answer 2

I pay that law/suggestion no mind whatsoever. It defeats half the benefit of aggregation and composition, and I won't have it.

Answer 3

I think they're really orthogonal. REST describes a collection of resources addressed by URIs with a set of canonical methods: GET, POST, etc. If REST routine returns a URI, that's not "reaching through" it's identifying a different object with the same method names.

Answer 4

A link that is provided by a representation, exposed by a RESTful interface, can be completely opaque without violating any of REST's constraints. Therefore I would suggest that REST is completely consistent with the Law of Demeter. There is no requirement that the link expose the structure of the URL space in its URL.

e.g. in an object oriented scenario, you might replace the call a.b.c with a.bc

In a RESTful representation you could create the following:

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

instead of doing

GET a

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

GET b

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

GET c

I would have to disagree with altCognito and say that one of the main goals of REST is loose coupling. The uniform interface, standard media types and HATEOAS all combine to produce an extremely loosely coupled interface.

In response to David's comment:

REST is all about super-loose coupling to the point where it is pointless for the provider to try to anticipate all the needs of the clients

Actually, REST is about limiting the clients options by providing only valid links in the representations. Within those constraints the client can attempt to satisfy its own needs. It is by removing the knowledge from the client of when certain requests can be made that you achieve loose coupling. Loose coupling is not achieved by listing a set of resources and saying "ok, you can GET, PUT, POST, DELETE all you want."