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, PUT updates records, POST 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.