一般与特定端点 - Restful API 设计

Question

是否有充分的理由不为所有资源制定一个通用端点，和/或将所有资源概括为一个？

Facebooks Graph API 似乎就是这样构建的。 没有/api/users 、 /api/companies等。或者它可能只是一个通用接口来与服务器上的不同资源进行对话？

显然，如果不同的资源具有相似的功能，这种方法可以减少后端的大量代码复制。

Answer 1

是否有充分的理由不为所有资源制定一个通用端点，和/或将所有资源概括为一个？

是的——但这些原因并不适用于所有情况。

如有疑问，请查看Fielding 论文的第 5 章。

REST 接口被设计为高效的大粒度超媒体数据传输，针对 Web 的常见情况进行优化，但导致接口对于其他形式的架构交互不是最佳的。

特别是关于资源——Ian Robinson 在他的演讲中谈到了其中的一些内容： The Counterintuitive Web

专业化和创新取决于开放集。

在 RPC 中，端点集是关闭的，而可以发送给它的消息集是开放的。 您通过创建新消息进行创新。 在 REST 中，消息集是关闭的，而端点集是开放的——您通过创建新的端点来进行创新。

后一种方法的一个优点是您可以使用通用组件来分发工作，因为它们只需要对有限数量的消息进行有限的理解。 例如，缓存不需要了解您的有效负载的细节和意图来确定要做什么； 他们只需要标识符和一些标准化的元数据，就可以了。

现在，以 GraphQL 为例，有 一个缓存故事。 但不要忽视：该策略不是“哦，只需插入任何商品 Web 缓存”。

课程用马； 这是一种权衡，而不是对/错的二分法。 如果您的项目非常成功，以至于只有 REST 架构约束才能拯救您，那么您已经将问题交给了其他人，并退休到您最喜欢的热带岛屿。