Rest 邮政中的可变有效载荷

这更像是一个设计问题。假设我有一个端点来创建一个家。每个家庭都有地址和其他特征。现在让我们关注地址

设想一个传统的世界，在那里我们可以使用一个包含地址id的有效负载（该地址id是对具有地址验证等的外部系统的引用）发送到/主页

现在，我们希望支持创建地址（在外部系统中），以简化客户需要拨打的电话数量。客户会/可以直接打电话给我们，用指定的地址值创建一个家，而不是2个电话

使用指定的地址id或地址值字符串（但不能同时使用两者）输入发送至/主页。这将使我们的服务器查看负载内部，决定是否需要代表客户端调用外部地址系统，这取决于POST负载中显示的字段（地址id vs地址值）

问题: 基于请求中字段的变量行为，感觉像是反模式。它还感觉像是一个传统领域和我们试图支持的新领域之间的紧密耦合

另一种选择是，我们引入一个新端点，它接受一个只有地址值的新有效负载，并最终使用address_id弃用旧端点

还有其他的设计方案吗

基于请求中字段的变量行为，感觉像是反模式

这可能不像感觉上那样是一种反模式

从历史上看，SOAP和最近的GraphQL都是“将有效负载发布到资源，我们将在另一端找到它”

HTTP是一种应用程序协议，其应用程序域是通过网络传输文档。-

REST限制我们使用有限的一组信息——“五个动词和真相”——因此肯定会有一些信息在某个地方同时出现

我们希望POST处理多种消息的原因是缓存失效规则应用于目标资源。因此，我们希望使用目标，这些目标包含客户端缓存的正确表示

因此，在HTML中，我们可能有许多不同的表单，它们都发布到单个资源，因为成功处理这些表单会使该资源的缓存表示无效

是的，这意味着在服务器端，当我们正在使用的框架只支持基于请求元数据的路由时，我们可能需要手动滚动一些我们自己的路由逻辑

---

这并不是说您不能选择使用更细粒度的资源——这也没关系。但它们“应该”是有自己表示的资源，而不仅仅是每个“责任”都有不同拼写的RPC端点。

感谢@voiceofunreason的解释。这在更高的层次上是完全有意义的，我很好奇你对有效载荷中字段的想法。您如何看待有效负载中相互排斥的字段？例如，如果颜色、地址值和地址id是house POST有效载荷中的三个字段，那么在地址id和地址值周围引入有效载荷有效性规则不会同时提供？消息有效载荷基本上是一条消息，因此您需要设置一些约束以允许演化模式。我不认为您的模式不能包含互斥字段有什么特别的原因。