2016-10-30 56 views
1

假設我有不同種類的對象HouseCar。現在我想添加評論。JSON-API設計

最好的做法是什麼? 有終點:

/api/house/:houseId/comments

/api/car/:carId/comments

或者徵求意見一般般API:

/api/comments/:generalId

+0

沒有太多的API設計正規教育,我會說前者更好,因爲它更結構化 - 我認爲它是有一個productA.comments/productB.comments vs一個大數組註釋[] –

+0

我的關注點在於,在API代碼中,我從每個對象獲得對comments.model的依賴關係。所以API的可讀性比API代碼的結構更值得嗎? – Stefan

回答

4

我的產品類型是實現細節。要REST風格我會創建API與

/API /產品/的[ProductID]

此端點會詢問服務GET(獲取給定的產品),POST(更新指定產品),刪除

/API /產品/

該終端將支持GET(獲取所有的產品),PUT(創建新產品)

這個端點將支持GET(獲得給定產品的給定註釋)和POST(更新給定註釋),DELETE(刪除給定評論)。這個端點將支持GET(給定註釋)。 在這種情況下,commentID可能是唯一的每個資源,而不是全局。

/API /產品/的[ProductID] /評論

該終端將支持GET(獲取產品的所有評論)和PUT(創建新的註釋),刪除(刪除產品所有評論)

API /評論/ [commentId]

此資源(與操作GET,POST,DELETE)也很好。但它需要全球獨一無二的評論。如果您需要在不知道productId的情況下管理單獨的評論,請隨意公開此類端點。這並不違反REST。

在這個API設計中,我們爲每個產品和評論分別提供資源。 我們還擁有所有產品的資源,併爲給定產品的所有評論提供資源。每個資源可能支持GET,POST,PUT,DELETE。你可能ommit某些操作(例如不暴露於/api/product/[productID]/comments/[commentID]POST當你不希望支持編輯點評

編輯:。在由@lospejos評論建議你可以使用複數形式(產品,評論)無論哪種方式,你的API將是REST風格,每個帖子/評論都是獨立的資源。

+1

我同意除了我會在每個端點使用複數實體:'/ products','/ comments'等 – lospejos

+0

對不起,我在這個問題上還不夠清楚。產品不能只是一個端點。它更像/ api/house和/ api/car。我編輯這個問題以使其更加清晰。 – Stefan

+0

好的,所以make/api/house/[id]和/ api/car/id。或者在id中編碼產品類型,如/api/house.[house-id] /api/car.[car-id]/。無論哪種方式都需要RESfull,您需要爲每個獨立資源分配唯一的重新編號(URL)。 –