得墨忒耳与REST的关系

Question

Demeter法则（实际上应该是Demeter的建议）说你不应该“穿过”一个物体来获取他们的孩子物体。如果您作为客户端需要执行一些非平凡的操作，那么大多数情况下您正在使用的域模型应该支持该操作。

REST原则上是一个愚蠢的对象层次结构。它就像资源/对象的文件系统，其中每个对象都可以有子对象。您几乎总能通过REST实现目标。您可以选择使用REST技术构建按惯例复合对象类型，只要提供者和客户端就更高级别的操作达成一致，您就可以避免覆盖。

那么，你如何平衡REST和Demeter？在我看来，它们并没有发生冲突，因为REST完全是关于超松散耦合的，因为提供商试图预测客户端的所有需求是没有意义的，而Demeter认为逻辑可以迁移到它的通过重构最自然的地方。

然而，你可以说，在你更好地了解你的客户之前，REST只是一个止损。 REST只是一个黑客？ Demeter在任何服务器/客户端场景中都不现实吗？

Answer 1

• Demeter在任何服务器/客户端场景中都不现实吗？

我想你在这里回答了你自己的问题。在这方面，REST如何与SOAP或XML-RPC不同？

REST的要点不是提供超松耦合，而是以下内容：

• 提供准确描述所请求资源的标识符。
• 提供行为符合预期的服务GET请求是幂等的，PUT更新记录，POST创建，DELETE删除
• 最小化存储在服务器上的状态
• 消除不必要的复杂性

有些情况REST不是最佳答案，但REST的效果非常好。

Answer 2

我毫不介意地支付这项法律/建议。它击败了聚合和组合的一半好处，我不会拥有它。

Answer 3

由RESTful接口公开的表示提供的链接可以完全不透明，而不会违反REST的任何约束。因此我建议REST完全符合得墨忒耳定律。不要求链接在其URL中公开URL空间的结构。

e.g。在面向对象的场景中，您可以使用a.bc

替换调用a.b.c.

在RESTful表示中，您可以创建以下内容：

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

而不是

GET a

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

GET b

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

GET c

我不得不反对altCognito，并说REST的主要目标之一是松散耦合。统一的界面，标准的媒体类型和HATEOAS都结合在一起，形成了一个极其松散耦合的界面。

回应大卫的评论：

  

REST完全是关于超松散耦合，以至于提供商试图预测客户的所有需求毫无意义

实际上，REST是通过在表示中仅提供有效链接来限制客户端选项。在这些限制内，客户可以尝试满足自己的需求。通过从客户端移除知识，可以确定何时可以实现松散耦合。通过列出一组资源并说“好，你可以GET，PUT，POST，DELETE所有你想要的东西”来实现松耦合。

Answer 4

我认为他们真的是正交的。 REST描述了URI使用一组规范方法寻址的资源集合：GET，POST等。如果REST例程返回一个URI，那就不是“通过”它识别具有相同方法名称的不同对象。