REST與GraphQL的爭論

banq發表於2019-08-28
REST

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

相關文章