一般與特定端點 - Restful API 設計

Question

是否有充分的理由不為所有資源制定一個通用端點，和/或將所有資源概括為一個？

Facebooks Graph API 似乎就是這樣構建的。 沒有/api/users 、 /api/companies等。或者它可能只是一個通用接口來與服務器上的不同資源進行對話？

顯然，如果不同的資源具有相似的功能，這種方法可以減少后端的大量代碼復制。

Answer 1

是否有充分的理由不為所有資源制定一個通用端點，和/或將所有資源概括為一個？

是的——但這些原因並不適用於所有情況。

如有疑問，請查看Fielding 論文的第 5 章。

REST 接口被設計為高效的大粒度超媒體數據傳輸，針對 Web 的常見情況進行優化，但導致接口對於其他形式的架構交互不是最佳的。

特別是關於資源——Ian Robinson 在他的演講中談到了其中的一些內容： The Counterintuitive Web

專業化和創新取決於開放集。

在 RPC 中，端點集是關閉的，而可以發送給它的消息集是開放的。 您通過創建新消息進行創新。 在 REST 中，消息集是關閉的，而端點集是開放的——您通過創建新的端點來進行創新。

后一種方法的一個優點是您可以使用通用組件來分發工作，因為它們只需要對有限數量的消息進行有限的理解。 例如，緩存不需要了解您的有效負載的細節和意圖來確定要做什么； 他們只需要標識符和一些標准化的元數據，就可以了。

現在，以 GraphQL 為例，有 一個緩存故事。 但不要忽視：該策略不是“哦，只需插入任何商品 Web 緩存”。

課程用馬； 這是一種權衡，而不是對/錯的二分法。 如果您的項目非常成功，以至於只有 REST 架構約束才能拯救您，那么您已經將問題交給了其他人，並退休到您最喜歡的熱帶島嶼。