REST API-搜索條件（queryParams）未產生任何結果時返回的內容

Question

我正在設計REST API，並且在整個API中，當我們嘗試訪問的對象/資源不存在時，我們都使用HTTP Not found / 404。

Ex: http://host/someobject/1

但是當前的一種情況幾乎沒有什么不同。 我有使用查詢參數搜索數據的URI。

Ex: http://host/someObject/find?param1=param1value&param2=param2value

查詢參數是可選的，但必須至少提供一個條件才能成功請求。 當搜索結果為空時，我當前正在返回空列表，假設URI存在但當前不存在數據。

有人可以闡明這種情況嗎？ 我應該返回狀態碼為200或其他的空數組嗎？

Answer 1

TL; DR-使用N = 0返回與N個結果相同的結果。

http://host/someObject/find?param1=param1value&param2=param2value

請記住，從REST / HTTP的角度來看，上面的URI 不是查詢；它是一個查詢。 它是信息資源的標識符。 標識符的一部分（由RFC-3986命名為Query）僅是“非分層數據”。

您的實現會解析URI，並使用它找到的令牌作為查詢的輸入，這是一個實現細節，並且被統一接口故意從客戶端隱藏了。 （例如，考慮到客戶端GET請求通過客戶端和服務器之間的緩存傳遞的情況；緩存可能會將URI用作鍵值存儲區中的查找，並且-在其中查找表示形式-將發送結果返回給客戶端，而無需將請求轉發給服務器）。

理想情況下，即使您的實現可能不穩定，您的資源及其表示形式也將保持穩定。

查詢參數是可選的，但必須至少提供一個條件才能成功請求。 當搜索結果為空時，我當前正在返回空列表，假設URI存在但當前不存在數據。

完善。

我認為您的評論說我的實現很好嗎？

是。

我也發現有些人說動詞不應該在那兒，表示應該是賓語/？param = value或賓語？param = value。

快速概述

REST不在乎您對資源標識符使用什么拼寫。網絡也不是-就網絡的其他部分而言，您的URI是不透明的。 客戶端代碼不應解釋標識符，也不應以任何方式依賴它們的解釋。 唯一需要關心的是源服務器（它需要將標識符路由到適當的實現）。

您所引用的“規則”類似於為變量名推薦最佳實踐的編碼風格指南。 該規則的動機是基於REST和網絡的； 不是通過規范，而是通過更深層次的想法。

REST中信息的關鍵抽象是一種資源。 可以命名的任何信息都可以是資源：文檔或圖像，臨時服務（例如“洛杉磯今天的天氣”），其他資源的集合，非虛擬對象（例如人）等。 換句話說，任何可能成為作者超文本引用目標的概念都必須符合資源的定義。

REST組件通過使用表示來捕獲資源的當前或預期狀態並在組件之間傳輸該表示，從而對資源執行操作。

因此，任何返回表示形式的資源都必須是具有狀態的事物 。 因此，命名准則鼓勵將資源標識為名詞而非動詞的拼寫。

URI所說的是“找到滿足這些約束的對象”，但這與資源的概念不符。 該准則鼓勵您改而考慮“讓我了解滿足以下約束的對象集合的當前狀態”，然后選擇與該資源一致的標識符。

當我以不同的觀點閱讀這些不同的博客時，我很困惑

• 那不是你的錯
• 如果您以英語為母語，您仍然會感到困惑

大多數程序員會先研究一些東西，然后再問附近的人來學習其余的東西。 這意味着人們所擁有的許多實用“知識”都來自口頭傳統； 每當一個新人講述這個故事時，故事就會發生變化，並且它會與其他事物混淆。

在REST的情況下，歪曲到了一個地步，知道原始故事的人開始尋找要使用的新名稱，只是為了能夠重新引入原始想法。

Answer 2

我認為200（帶有空列表）和204（未找到內容）都是正確的實現。

200成功表示您能夠成功執行操作，並且正在返回結果。 空列表是有效的結果集。

204表示您成功嘗試的操作，服務器未返回任何內容。 因此這也是有效的。

RESTful的世界是如此精致，以至於它最終會取決於您的個人喜好，而我的個人喜好將為200，並且有空白列表。

Answer 3

404表示：404 –未找到–我要說的URI后面沒有資源，當URI和參數有效時，返回一個空列表是有效的。

您可以返回204：204 No Content