什麼是與關聯的資源REST服務的正確的URI設計

Question

大家好，

我是REST和Web API的新手。我對如何爲我的資源設計URI感到困惑。

鑑於我有一個域具有以下資源：博客，帖子和用戶。

Blog (1) ------ (0..*) Post (0..*) ------ (1) User 

一個博客可以有很多職位，每個職位與一個博客有關。用戶可以有很多帖子，每個帖子都與一個用戶相關聯。

對於博客和用戶資源的URI是這樣的：

GET /blogs - get list of all blogs 
GET /blogs/{id} - get blog by id 
POST /blogs - create new blog 
PUT /blogs/{id} - update blog 
DELETE /blogs/{id} - delete blog 

GET /users- get list of all users 
GET /users/{id} - get user by id 
POST /users - create new user 
PUT /users/{id} - update user 
DELETE /users/{id} - delete user 

但對於帖子資源？如何處理關聯？我正在考慮以下替代方案 - 哪些是正確的，爲什麼？

- 通過博客

1. GET /blogs/{id}/posts 
or 
2. GET /posts?blogid={id} 

獲取所有職位 - 在博客中

3. POST /blogs/{id}/posts 
or 
4. POST /posts (here I would then in the payload send the IDs of the resources this post is associated with. BlogId and UserId) 

創建新的崗位 - 通過博客，並通過用戶獲得的所有帖子

5. GET /blogs/{id}/posts?userid={id} 
or 
6. GET /posts?blogid={id}&userid={id} 

如果有人抱怨d在這裏指向正確的方向，我會很感激。

Answer 1

由於後總是與博客和用戶ID相關聯，我會選擇選項1，3和5：

GET /blogs/{id}/posts 
POST /blogs/{id}/posts 
GET /blogs/{id}/posts?userid={id} 

Answer 2

你應該問自己的第一個問題是它是你多麼重要你的API真的是RESTful？它實際上比實現這一點更加煩瑣。

1. 您的API是否僅由您自己的軟件\組織使用？

2. 您的API是否附有文檔？

如果答案爲1或2個以上爲真，則是真正的RESTful的價值是值得懷疑的...它全有或全無用REST所以無論你幹到底還是你不用擔心。

要使API成爲真正的REST API，它必須能夠從單個入口點發現（請參見：http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven）。每次調用應返回上可以對資源進行..通常是通過某種鏈接等相關的呼叫信息，這是一個可能的結構：

{ 
    "Id" : 1, 
    "Identifier" : "123's First Blog", 
    "links" : [ 
     { 
      "rel": "http://myapi/res/posts", 
      "href": "http://myapi/blog/1/posts" 
     }, 
     { 
      "rel": "http://myapi/res/users", 
      "href": "http://myapi/user/123" 
     } 
    ] 
} 

的版本是的一個總結\定義鏈接資源，並且href應該指向api本身。

無論如何，所有這一切的關鍵在於，如果你確實想成爲真正的RESTful，那麼就讓資源和uris之間的聯繫來規定設計。考慮如何從單一的起點發現每個呼叫的細節，並且結構應該像TDD一樣通過軟件設計來展示自己。

如果你不需要RESTful，那麼事情變得更簡單。只需以最自然的方式爲您，您的架構和開發人員設計您的API。如果你正確地記錄事情，那麼這將導致一個更有效的API，並且更快地發展。

馬里奧對這個問題的回答是合理的，我也會贊成這些選擇。我只是認爲你應該知道伴隨這樣一個desicion的整個故事。

如果這沒有意義，或者你想那麼更多的信息發表評論，我會盡力幫助:)