REST与GraphQL的争论

19-08-28 banq

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约束。

 

                   

1
猜你喜欢