REST API url設計

Question

我有一個 REST API 有一個帶有兩列的表的數據庫， product_id和server_id ，它將 product_ids 提供給請求數據的特定服務器（基於表中的server_id ）。 假設我有三台服務器，server_ids 為 1,2 和 3。

我的設計是這樣的： /products/server_id/1並且通過 GET 請求，我得到 json server_id = 1 的 product_ids 列表，類似/products/server_id/2將 output server_id = 2的 product_ids 列表。

我是否應該刪除這些路由並要求發送帶有指令的 POST 請求，以僅在/products路由中接收特定 server_id 的 product_ids？

例如，發送有效負載{"server_id":1}將產生server_id = 1的 product_ids 列表的響應。

Answer 1

我是否應該刪除這些路由並要求發送帶有指令的 POST 請求，以僅在 /products 路由中接收特定 server_id 的 product_ids？

通常不會，不會。

GET向通用組件傳達請求消息的語義實際上是只讀的（請參閱“安全” ）。 僅這種可供性就使許多事情成為可能； 例如，蜘蛛可以抓取和索引您的 API，就像它們對 web 站點一樣。 用戶代理可以“預取”資源，等等。

當您決定使用 POST 時，所有這些都可以直接使用 window。

此外，URI 本身有許多有用的用途——緩存使用 URI 作為匹配請求的主鍵。 因此，我們可以通過重用已使用特定標識符存儲的表示來減少源服務器的負載。 我們還可以執行魔術，例如將該 URI 粘貼到 email 消息中，而無需任何特定 HTTP 請求的上下文，並且消息的接收者將能夠獲取該標識符並獲取我們想要的資源。

同樣，當識別信息在請求有效負載中而不是在它所屬的標識符元數據中時，我們會丟失所有這些信息。

也就是說，我們有時確實使用有效負載來識別信息，作為一種解決方法：例如，如果我們需要太多的識別信息以至於我們開始看到414 URI Too Long響應，那么我們可能需要更改我們的交互協議以使用帶有有效載荷中的識別信息的 POST 請求（如上所述，失去了使用 GET 的優勢）。

這方面的在線示例可能類似於 HTML 驗證器，它接受候選文檔並返回發現問題的表示。 這實際上是一個只讀操作，但在一般情況下，HTML 文檔太長，無法輕松放入 HTTP 請求的目標 uri。

所以我們踢。

在超媒體 api中，就像在世界范圍內使用的 web 一樣，我們可以擺脫它，因為 HTTP 使用的元數據方法是由服務器作為其自身形式的一部分提供的。 您作為客戶端不需要知道服務器的首選語義，您只需要知道如何處理表單數據。

例如，當我在瀏覽器中輸入這個答案時，我不需要知道目標 URI 是什么，或者將使用什么 HTTP 方法，因為瀏覽器已經知道要做什么（基於 HTML 等等腳本正在“按需”運行）。

Answer 2

在 REST API 中，POST 請求只能用於創建新資源，因此為了從服務器檢索數據，最佳實踐是執行 GET 請求。

例如，如果你想在服務器 9 上加載產品 1、2、4、8，你可以使用這種請求：

GET https://website/servers/9/products/1,2,4,8

在服務器端，如果 products 值包含一個逗號分隔的列表，則返回一個包含所有結果的數組，如果不返回一個只有一項的數組，以保持調用之間的一致性。

如果您需要獲得所有產品，您只能保留以下 url：

GET https://website/servers/9/products

由於 products 參數中沒有提供 id，因此服務器應為請求的服務器參數返回所有現有產品。

注意：如果結果量大，必須分頁。