REST API - 包含相關對象的詳細信息或只是ID的

如果我有一個對象，它包含例如我有車對象一些相關的對象和它的各種類型。

我應該要求api.example.org/cars/1只需用ID對這些資源的響應（所以如果有人需要有關它們的詳細信息在api.example.org/type/1需要另一API調用）

{ 
    "id": 1, 
    "name": "Some Car", 
    "types": [ 
     1, 
     2 
    ] 
}

或提供詳細關於這些資源以及

{ 
    "id": 1, 
    "name": "Some Car", 
    "types": [ 
     { 
      "id": 1, 
      "name": "Some Type", 
      "something": "Blah" 
     }, 
     { 
      "id": 2, 
      "name": "Some Type", 
      "something": "Blah" 
     } 
    ] 
}

或者提供像「displayAll」這樣的可選參數，然後在一個API調用中應該全部檢索參數名稱的數組（在這種情況下爲類型）。

來源

2012-02-18 svenkapudija

這觸及了REST的核心原理之一HATEOAS（超媒體作爲應用程序狀態引擎）。

對象ID是無用的，毫無意義的客戶。你對他們做什麼？將它們饋送到搜索功能？構造一個新的URI並將它們追加到它的結尾？撥打1-800號碼並詢問如何處理他們？在紙上打印出來並寄給政府機構，幫助API客戶找到他們的下一步？

只返回完整的URI，所有的時間。給客戶端的ID應該始終是URI--它是唯一標識所討論的資源的東西，可以用來檢索，更新或刪除它。

來源

2012-02-18 17:31:21

的問題是：如果你不分離的根URL和ID，如果根URL變動（V1到V2，或諸如此類的東西），那麼前面所有的鏈接將被打破，不是嗎？是否沒有使用情況下需要集中根目錄來引導客戶端？ – 2014-12-12 02:55:37

保持一個永遠不應該改變的穩定的「酷」URI的數量非常少，並通過超鏈接導航可以使其下的每個其他URI。客戶端應用程序應該編碼爲從Cool入口點URI開始，並通過導航這些關係來查找他們需要的資源。這是HATEOAS的核心部分 - 您的URI結構的大部分應該靈活且隨需求變化而變化，但不會影響現有的應用程序。 – 2014-12-12 16:10:27

我寧願選擇1的參數的版本，但我贊成一些地方返回類型資源的位置，從而使客戶可以選擇是否要獲取這些資源。

否則，我們沒有導航的文件。相反，我們將依賴一些帶外數據，例如事先知道類型的路徑。

{ 
    "id": 1, 
    "name": "Some Car", 
    "types": [ 
     { 
      "location": "api.example.org/type/1" 
     }, 
     { 
      "location": "api.example.org/type/2" 
     } 
    ] 
}

來源

2012-02-18 10:54:52

REST API - 包含相關對象的詳細信息或只是ID的

回答

相關問題