路徑參數的REST API URL模式

我正在構建一個Backbone應用程序，該應用程序顯示來自特定技術手冊的圖表的交互式傳真。每個手冊都有許多圖表類型（比如A-Z），分佈在其頁面上。每個圖表可能在頁面上出現多次，有時單個頁面可能包含給定圖表類型的多個實例。路徑參數的REST API URL模式

我有一個Django後端服務於我的前端使用的REST API。我一直在努力的是該請求的網址設計。我嘗試了幾種模式，其中沒有一種能讓我滿意。我的Django的模型看起來是這樣的：

class Diagram(models.Model): 
    type = models.CharField(max_length=1) 
    page = models.IntegerField(default=1) 
    order = models.IntegerField(default=1) 
    data = JSONField(default='{}')

的order領域涉及的情況下，有一個頁面上指定的圖表類型的多個實例。這個模型的表是隻讀的，所以我只是在做簡單的GET s。用戶一次只能查看一個圖表實例。按照類型，頁面和（相關）順序選擇圖表。我最初的URL設計是這樣的：

example.org/api/diagrams/A/pages/1/order/2/

雖然有多個圖表，該diagrams PARAM暗示的集合 - 但是圖並不「包含」頁面。與pages param一樣。顯然order只能是單數。因此，或許：

example.org/api/diagrams/type=A/page=1/order=2/

或許只是去與查詢參數：

example.org/api/diagrams/?type=A&page=1&order=2

我個人比較喜歡的路徑參數，但這樣做的主要併發症是，order參數是實際上是多餘的大部分時間 - 在頁面上只有少數幾個重複圖的情況（目前我默認order爲'1'，無論是在後端還是在請求中）。因此，也許路徑和查詢參數的組合：

example.org/api/diagrams/A/page/1/?order=2

這是一個很好的模式？我可以考慮其他選擇嗎？

編輯：一些額外的閱讀（特別是URI Standard）之後，我覺得的答案是一個路徑參數設計適合於層次結構...這似乎直觀。但我沒有，所以正確的候選人是純粹的查詢參數設計。對？

來源

2016-02-21 ChrisM

我可以建議一種不同的方法嗎？我知道，這可能不是你正在尋找的答案，但是不要試圖從你的代碼中發佈確切的對象模型，而是想想客戶端需要看到什麼樣的資源以及它與什麼有關。

例如，如果客戶端需要「瀏覽」圖表，您可以有2 media-types，一個用於列出所有圖表，以及一個圖表本身。這些URI可能是：

/api/diagrams/   <-- list of all diagrams with titles 
/api/diagrams/1   <-- a single diagram 
/api/diagrams/2 
...

如果客戶需要每頁手動瀏覽，那麼你就可以提供那些過於有代表手冊（頁面列表）額外media-types，並與鏈接到圖中的頁面是在上面。例如：

/api/manuals   <-- list of all manuals 
/api/manuals/1  <-- list of pages, maybe a list of all diagrams in manual 
/api/manuals/1/page2 <-- list of diagrams on page2

對於您瀏覽每個訂單和圖表類型的情況也是如此。

如果您只需要一個「搜索」API而不是「瀏覽」API，那麼正確的解決方案就是創建一個「表單」，您可以在其中提交信息（訂單，類型，頁面等）。）。所以這將是2 media-types，一個用於搜索描述，可能還有一個用於圖表。

問題是，如果您嘗試創建REST API，則不應修復URI。服務器應該將URI提供給客戶端（除了起始URI，例如搜索頁面）。

這有幾個好處，一個是你可以在服務器上控制你的URI。如果你不想要，你不必是RESTful，但即使如此，如果你控制客戶端，URI本身並不重要。客觀的措施都不是你的方法是錯的。

對不起，如果這沒有幫助:)

來源

2016-02-22 09:09:28

非常感謝你對此的見解，他們非常感謝。 – ChrisM

路徑參數的REST API URL模式

回答

相關問題