RESTful Web服務：通過組合其他資源創建新資源：提供ID或URI？

從REST風格的Web服務（通過GET）獲取項目集合時，每個單個項目（例如JSON）的表示通常包含項目的資源標識符。這可以是資源ID爲或ID爲的整個URI通常包含該ID。RESTful Web服務：通過組合其他資源創建新資源：提供ID或URI？

如果客戶端需要進一步與代表單個項目的遠程資源進行交互，則需要此標識符（ID或URI）。許多人似乎認爲提供完整的URI而不僅僅是ID是好的做法，因此客戶端與URI構造無關（例如，這是Miguel Grinberg在this文章中寫的）。

但是，如果多個項目要合併以創建新資源，應該怎麼辦？然後客戶端需要告訴服務器哪些項目將被組合。最終，服務器需要一個ID列表來處理請求。假設客戶端首先檢索每個項目的URI - 您將在哪裏執行URI解析以便再次提取原始ID：在客戶端還是在服務器中？

示例：客戶端在GET請求中檢索到頁面集合。每一頁項標識本身與URI（包括ID）：

{ 
    "pages": [ 
    { 
     "content": "bla bla", 
     "uri": "/pages/1" 
    }, 
    { 
     "content": "that is no interesting content", 
     "uri": "/pages/2" 
    }, 
    ... 
    ] 
}

現在假設客戶端指示服務器創建新的資源組合多個頁面：一個書，由1和2頁建成。 POST請求體可以包含ID或URI的：

{ 
    "title": "A Boring Book", 
    "pages": [1, 2] 
}

或

{ 
    "title": "A Boring Book", 
    "pages": ["/pages/1", "/pages/2"] 
}

在第一種情況中，客戶端需要在發送請求之前知道URI的結構並提取ID。在第二種情況下，服務器需要從URI中提取ID。

一方面，我喜歡通過URI 只在的客戶端表示資源的想法。另一方面，我還想保持簡單和實用的原則，爲什麼當上下文清楚並且只需要標識符（創建書本而不是直接作用於頁面資源）時，我們應將整個URI發送到服務器？

您更喜歡什麼？爲什麼？或者你認爲這真的不太重要？

您認爲以下方法是一個很好的折衷方案嗎？通過從右向左解析URI並在最右斜槓之後提取數字，即假設某個URI結構不需要硬編碼整個路徑，客戶端從URI中提取ID。

來源

2014-11-06 Jan-Philip Gehrcke

我認爲客戶端應該從服務器接收絕對URL並且只使用這些URL而不做任何修改。因此，我甚至會走一步超越你的最後一個例子：

{ 
    "title" : "A Boring Book", 
    "pages" : [ "http://.../pages/1", "http://.../pages/2" ] 
}

只有服務器應該負責，如果需要從URL中提取的ID。

來源

2014-11-07 08:12:46 braunpet

感謝您的回答。如果這不是公共API（即，您是唯一一個寫*客戶端），您是否也會這樣做？您將分配給帶寬最小化的哪個優先級，特別是當您定位移動設備時？那麼你可能會忽略'http：// location.com'部分？ – 2014-11-10 17:49:56

即使在非公開的API中，我也只會使用絕對URL。如果您對網絡帶寬有所顧慮，那麼我認爲REST不是最佳選擇。 – braunpet 2014-11-11 16:35:42

RESTful Web服務：通過組合其他資源創建新資源：提供ID或URI？

回答

相關問題