其餘api設計問題 - 查詢元素的嵌套url params或url

我使用express作爲路由器與mysql。其餘api設計問題 - 查詢元素的嵌套url params或url

博客和評論是數據庫（MySql）中的兩個實體並且通過外鍵相關。

傳統的REST API的設計將是象下面這樣：

blog/:blogId 
blog/:blogId/comments/:commentId

我喜歡下面，因爲我不想要一個嵌套的思想路線同等的 - 而不是所有附加的東西將在請求查詢。這種代碼模塊化並且不會在後端鏈接。

blog/:blogId 
comments/:commentId?blog=blogId

我知道它有點違背rest api的粒度。

如果我繼續使用apis，我在想什麼？任何人都可以指出一個例子。

來源

2016-10-14 npr

那麼，傳遞數據作爲查詢參數是不可取的。通常在規範中，查詢參數數據是那些不是強制性的數據，換句話說，即使你不傳遞查詢參數，API也不應該失敗，在你的情況下，如果blogId沒有傳遞它將返回的評論？我認爲blogId爲必填字段

但是你可以使用類似

blog/:blogId 
    comments/:commentId/blog/:blogId

但我理解你的關係的憂慮作爲博客是不是評論的孩子是一個會從API簽名看，但後來能我們在API簽名中實現了確切的關係？

來源

2016-10-14 13:24:43

對於你的問題什麼會api：評論/：commentId返回 - 錯誤：blogId失蹤。我可以在這裏彎曲規則/規範 - 但從技術上講，會有短暫的進展。 – npr

我真的沒有看到任何問題，從技術上選擇API名稱，REST非常靈活。 –

過了一分鐘 - 我覺得對錯誤的原始錯誤的blogId錯誤 - 錯誤應該是：錯誤無效的URL - 這是當我們比較'權利休息'的實施。我一直在思考的一點是 - 我想避免在博客模塊中有評論路由模塊。因此，如果我使用傳統的方式定義路線博客/：blogId在博客模塊和博客/：blogid/comments /：commentId在評論模塊中 - 需要檢查這是否可以使用express。 – npr

其餘api設計問題 - 查詢元素的嵌套url params或url

回答

相關問題