是否有充分的理由不为所有资源建立一个通用端点，和/或将所有资源概括为一个？
Facebook 的 Graph API 似乎就是这样构建的。没有/api/users、/api/companies 等。或者它只是一个通用接口来与服务器上的不同资源通信？
如果不同的资源具有相似的功能，这种方法显然可以减少后端的大量代码复制。
【问题讨论】：
标签： rest api facebook-graph-api restful-architecture api-design
是否有充分的理由不为所有资源建立一个通用端点，和/或将所有资源概括为一个？
是的——但这些原因并不适用于所有情况。
如有疑问，请查看Chapter 5 of Fielding's dissertation。
REST 接口旨在高效地进行大粒度超媒体数据传输，针对 Web 的常见情况进行了优化，但导致的接口对于其他形式的架构交互不是最佳的。
特别是关于资源——Ian Robinson 在他的演讲中谈到了其中的一些内容：The Counterintuitive Web
专业化和创新取决于开放集。
在 RPC 中，端点集是封闭的，而可以发送给它的消息集是开放的。您通过创建新消息进行创新。在 REST 中，消息集是封闭的，而端点集是开放的——您通过创建新端点来进行创新。
后一种方法的一个优点是您可以使用通用组件来分发工作，因为它们只需要对有限数量的消息进行有限的了解。例如，缓存不需要了解有效负载的详细信息和意图来确定要做什么；他们只需要标识符和一些标准化的元数据，就可以了。
现在，使用 GraphQL，有 a caching story。但不要忽视：该策略不是“哦，只需插入任何商品网络缓存”。
课程用马；这是一种权衡，而不是正确/错误的二分法。如果您的项目取得了灾难性的成功，以至于只有 REST 架构约束可以拯救您，那么您已经将问题交给了其他人并退休到您最喜欢的热带岛屿。
【讨论】：