这更多是一个设计问题。可以说我有一个端点来创建房屋。每个家庭都有一个地址和其他特征。现在让我们集中讨论地址。
设想一个旧世界，我们可以在其中使用包含address_id的有效载荷发布到/ home，该payload是对具有地址验证等的外部系统的引用，等等。
现在，我们希望支持（在外部系统中）创建地址，以简化客户需要拨打的电话数量。一个客户会/可能会打电话给我们来创建一个房屋，并指定地址值，而不是2个电话。
使用指定的address_id或address_value字符串（但不能同时使用两者）输入到/ home的POST。这将使我们的服务器在有效负载内部查看，决定它是否需要代表客户端调用外部地址系统，具体取决于POST有效负载中显示的字段（address_id与address_value）。
问题： 基于请求中字段的可变行为感觉就像是一种反模式。感觉就像是我们试图支持的旧字段和新字段之间的紧密耦合。
另一种选择是，我们引入一个新的终结点，该终结点采用一个仅具有地址值的新有效负载，并最终使用address_id弃用旧的终结点。
还有其他设计选择吗？
答案 0 :(得分：1)
基于请求中字段的可变行为感觉就像是一种反模式。
它可能比感觉上要少。
从历史上看，SOAP和最近的GraphQL一直都是“将有效负载发布到资源，我们将在另一端解决它”。
HTTP是一种应用程序协议，其应用程序域是通过网络传输文档。 -Jim Webber, 2011
REST限制我们使用一组有限的消息-“五个动词和真相”-因此在某处肯定会加倍。
我们期望POST处理多种消息的原因是缓存无效规则适用于目标资源。因此，我们要使用目标invalidate客户端已缓存的正确表示形式。
因此在HTML中，我们可能有许多不同的形式，所有的POST都发布到一个资源上，因为对这些形式的成功处理会使该资源的缓存表示形式失效。
是的，这意味着在服务器端，当我们使用的框架仅支持基于请求元数据的路由时，我们可能需要动用一些自己的路由逻辑。
这并不是说您不能选择使用更细粒度的资源-也是可以的。但是它们“应该”是具有自己表示形式的资源，而不仅仅是每个“职责”具有不同拼写的RPC端点。