1. 我不介意REST与GraphQL的争论，但是如果你看到像“你有过度获取/不足获取（over/under-fetching）的REST”这样的论点，这对REST来说不是问题，那就是糟糕的API设计。辩论需要以真正的问题为中心 就像有人抱怨SQL有一个“over/under-fetching”的问题，因为开发人员只写了一个SQL语句：“SELECT * FROM <OneTable>”
2. 我认为关键是可以*设计一个支持查询粒度的REST API（例如，字段选择器，扩展相关模型等），但是必须自己设计和构建它。
3. 其实我最喜欢的是使用两者。当与CQRS一起使用时，我有命令API的REST和查询API的GraphQL。它们是分开的，因为它们完成不同的工作并具有不同的工作负载和复制因子。
4. 我自己也是一个REST粉丝，但事实是，graphQL可变性非常适合于命令。
5. 我喜欢并开发REST API，但我不同意over fetching过度获取信息=破碎有缺陷。这取决于业务案例，也就是说，自己是唯一的消费者？还是第三方也会使用此API端点？他们是否需要我添加一些我可能不需要的其他信息？
6. 如果over fetching过度获取的数据大小不显着，我没有看到问题。如果API变得庞大且管理起来很麻烦，我确实看到它失去控制。其他数据只是放入模型与优化等等......
7. 支持GraphQL的人认为REST是糟糕的API设计的原因。
8. 辩论应该围绕范式本身的差异。REST是一种以资源为中心（又称为关系型DB），侧重于状态，而不是操作。GraphQL最初解决了一个特定的查询问题，并且添加了变动作为一种思考（RPC风格）。
9. HTML有链接和表单，这些是操作。REST中没有任何东西会迫使您以关系数据库的方式进行思考
10. RESTful规定使用类似于CRUD的HTTP动词，如GET，POST，PUT和DELETE。
11. REST是针对资源，但没有规定任何资源如何设计。将资源与DB记录等同起来是不正确的假设。在实践中，我几乎*从不*使用PUT / DELETE因为我不能轻易保证幂等性或符合HTTP约束。