當提供無效的查詢參數時，REST API是否應返回4xx響應？

Question

考慮一個RESTful API，它接受GET請求來列出項目：

GET /1.0/items/
>> {"items": [{}, {}, ..., {}]} # All items returned

現在考慮每個項目都有一個顏色字段，我可以過濾我的項目：

GET /1.0/items?color=blue
>> {"items": [{}, {}, ..., {}]} # Only blue items returned

如果我的API收到無效的查詢參數 （不是有效查詢參數的無效值）：

GET /1.0/items?notvalid=blue

預期的行為應該是什么？ 我的API應該返回4xx響應，通知客戶端請求是無效的，還是API應該執行項目列表，就像沒有提供過濾器參數一樣？

Answer 1

我的API應該返回4xx響應，通知客戶端請求是無效的，還是API應該執行項目列表，就像沒有提供過濾器參數一樣？

/1.0/items?notvalid=blue標識資源。 此標識符可以解釋為分層部分和查詢（請參閱RFC 3986，第3節 ），但標識符是整個事物。 面向不存在的資源的URI的文檔存儲將響應404錯誤。 所以這種行為是完全可以接受的（人們也可能使用更一般的400錯誤，但這並不常見）。

另一種具有優點的方法是使用必須忽略的策略。 將URI視為鍵值對的x-www-form-urlencoded表達式，可以自由地接受查詢，忽略未識別的鍵，並為缺失的任何鍵提供默認值。

采用這種方法，這個標識符將被視為拼寫為/1.0/items? 這為您提供了一些防止變更的保護（客戶端和服務器不需要具有完全一致的進展）。

注意：在REST中 - 客戶端通常會消耗超媒體表示來引導它完成協議; 因此，客戶端將通過表單或uri模板發現哪些參數是預期的查詢字符串的一部分。 這實際上只是必須忽略的語義，但在不同的地方應用。

如果API執行項目列表，就好像沒有提供過濾器參數？

您可能希望明確標識要返回的引用，以便客戶端可以檢測到差異; 例如，通過將請求重定向到您要返回的標識，或者返回Content-Location標頭。

Answer 2

根據JSON API文檔：

在大多數情況下，JSON API要求服務器在遇到JSON API定義的查詢參數的無效值時返回錯誤。 但是， 對於特定於API的查詢參數（即那些未由JSON API定義的參數），服務器可以選擇忽略無效參數並使請求成功，而不是響應錯誤 。

這是我通常在API上看到的行為。