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