Rest資源始終由Id？

Question

在RESTfull API中，表示資源過濾的最佳方式是什麼？ 大多數示例都提到了結構爲/resouce/9/subresource/5的URL。我希望代表一個像這樣的資源的過濾列表：/resource/9/subresource/validated。這個validated屬性是API領域中的頂級概念。

這是restfull api認爲'好嗎'？將驗證移動到查詢字符串感覺就像減少了這個概念的重要性。

編輯

讓我試着解釋我的問題有具體的例子：該api of stackexchange有以下資源：/users/{id}/notifications/unread。有人可能會爭辯說，未讀通知列表可以被視爲一種資源。

Answer 1

如果你想要一個純粹的REST API，請記住，每個資源類型是由同一個URL代表，所以像/resouce/9/subresource/5應該返回的東西比/resource/9/subresource/validated很大的不同。

我知道的大多數API使用查詢參數來獲取資源的一個子集（例如，用於過濾，分頁等）。在你的情況下，這些網址就像/resource/9/subresource?validated=true

一些API遵循不同的方法，並有特定的URL作爲過濾器（如你的/validated例子）。這背後的原因通常是，人們認爲API的複雜性可能會非常大......如果設計不正確，就是這種情況。試想一下，如果你查詢整個集合分頁的作品，但在其他參數設置一些參數纔有效，例如情況下不得，如果你只想要validated資源，與文檔質量很差混合）

關於移動validated查詢字符串..你能澄清爲什麼它會減少驗證的概念？就REST API而言，資源是國王，而不是資源的屬性。

（注意：我不知道你怎麼在網址中使用反斜槓）

編輯

試圖回答您的評論，因爲我覺得這是很重要的！ :)。

如果這些網址返回包含相同的資源列表，比方說，一個用戶，然後確認，刪除，foobared等都是狀態的用戶，而用戶是資源。

當我開始構建REST API時，我有類似的疑問，並且它確實需要思維轉換。 URL必須表示資源，而不是狀態或操作/命令。

編輯2

好吧，這解釋了混亂。 Stack Exchange API ...實際上不是一個REST API（在該頁面上甚至沒有提到REST這個詞）。它更像是一個RPC over HTTP，它使用JSON作爲表示。

澄清上述聲明（並在我被踢出網站之前）。REST通常被解釋爲有4個級別，您可以在此博客帖子上閱讀Haters gonna HATEOAS。我在這裏複製了關於符合REST級別的相關部分之一。

1. 「POX的沼澤」您正在使用HTTP進行RPC調用。 HTTP僅用作隧道。
2. 資源。您不需要每次調用服務端點，都可以使用多個端點來表示資源，並且您正在與他們交談。這是支持 REST的最初階段。
3. HTTP動詞。這是Rails爲您提供的開箱即用級別：您可以使用HTTP動詞 與這些資源進行交互，而不是始終使用POST。
4. 超媒體控件。 HATEOAS。您100％符合REST。

的StackExchange API是至多2級（1級將是使用類似SOAP 1個端點）。就我個人而言，如果它至少使用HTTP動詞，我只會將API識別爲「REST」，否則它仍然是RPC over HTTP，但唯一的區別是您有幾個端點。

所以也許你的問題是：你想在你的API中實現什麼級別的REST？在這裏謹慎的說一句，儘管HATEOAS可能聽起來很酷，但它會增加應用程序的複雜度......所以你必須問自己，如果你付出額外的複雜性是可以的（例如自動發現新操作） 。

非常重要的是，構建您認爲最容易爲您的客戶使用的API。最好採取一種實用的方法來處理REST，而不是宗教式的方法，例如，這裏是US White House REST standards。給我一個閱讀，我真的同意大部分，如果不是全部，那裏的做法。