每个实体的REST API设计

Question

我们每个实体应该有一个REST API端点吗？ 例如，我们有员工，他有办公地址，个人地址和其他一些地址。 当消费者请求员工详细信息时，我们是否应该返回“firstName，lastName和地址ID”，并且消费者会触发另一个地址对象查询。 我们如何选择哪种方法以及有助于做出此类决策的准则。

Answer 1

我们每个实体应该有一个REST API端点吗？

“RESTful接口通常会拥有比核心域模型中的域对象多得多的资源。” - 吉姆韦伯（2011）

当消费者请求员工详细信息时，我们是否应该返回“firstName，lastName和地址ID”，并且消费者会触发另一个地址对象查询。 我们如何选择哪种方法以及有助于做出此类决策的准则。

记住Web应该如何工作是很有用的。 Fielding描述了Web架构在他的论文的第4章中要解决的许多问题：

超媒体的定义是信息呈现中嵌入的应用程序控制信息的存在，或者作为上层的信息呈现。 分布式超媒体允许将演示和控制信息存储在远程位置。 就其本质而言，分布式超媒体系统内的用户动作需要将大量数据从存储数据的位置传输到使用它的位置。 因此，Web架构必须设计用于大粒度数据传输。

换句话说，如果您要在Web规模上运行， 缓存是一个重要的问题。

如果员工的详细信息是稳定的，那么将所有这些信息都扔进一个长期存在的文档中就很棒了 - 该文档可以长时间服务于许多请求。 另一方面，任何从文档的缓存副本工作的客户端都没有看到最新的更改 - 易失性数据通常希望从稳定数据中获得不同的缓存规则。

细粒度资源往往更容易编辑 - 在HTTP中，PUT取代了资源的状态。 较小的资源意味着客户端跟踪的数据较少，与其他编辑冲突的可能性较小。

Answer 2

我们每个实体应该有一个REST API端点吗？

世界上没有普遍的规则。 编程只是科学的一半。 这是另一半的艺术。 你决定选择什么。 如果不了解您的背景，我们无法为您提供建议。

例如，我们有员工，他有办公地址，个人地址和其他一些地址。 当消费者请求员工详细信息时，我们是否应该返回“firstName，lastName和地址ID”，并且消费者会触发另一个地址对象查询。 我们如何选择哪种方法以及有助于做出此类决策的准则。

试着看看它是如何在Facebook Graph API中实现的 。 简而言之：只需使用一个表示字段/依赖对象列表的查询参数，这些参数需要包含在结果中。