考慮接受GET請求列表項的一個RESTful API：當提供無效查詢參數時，REST API是否應返回4xx響應？
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是否應該執行項目列表，就好像沒有提供過濾器參數一樣？
我的API是否應該返回4xx響應，通知客戶端請求無效，或者API是否應該執行項目列表，就好像沒有提供過濾器參數一樣？
/1.0/items?notvalid=blue標識資源。該標識符可以解釋爲分層部分和查詢（請參閱RFC 3986, section 3），但標識符是整個事物。面對不存在的資源的URI的文檔存儲將響應404錯誤。所以這種行爲是完全可以接受的（也可能使用更一般的400錯誤，但這並不常見）。
另一種方法，它的優點是使用must ignore策略。將URI作爲鍵值對的x-www-form-urlencoded表達式處理，可以查詢，忽略未識別的鍵，併爲缺失的任何鍵提供默認值。
採取這種方法時，該標識符將被視爲拼寫爲/1.0/items?這可以爲您提供一些防止更改的保護（客戶端和服務器無需完全一致地取得進展）。
注意：在REST中 - 客戶端通常會使用超媒體表示來引導它通過協議;因此客戶端會通過表單或uri模板發現哪些參數是查詢字符串的一部分。這實際上是一樣必須忽略的語義，但是應用在不同的地方。
API應該執行項目列表，就像沒有提供過濾器參數一樣？
您可能希望明確標識您要返回的參考，以便客戶端可以檢測出差異;例如將請求重定向到要返回的標識，或者返回Content-Location標頭。
根據JSON API文檔：
在大多數情況下，JSON API要求服務器在遇到一個JSON API定義的查詢參數值無效返回一個錯誤。但是，對於特定於API的查詢參數（即那些未由JSON API定義的參數），，服務器可能會選擇忽略無效參數並使請求成功，而不是以錯誤進行響應。
這是我通常在API上看到的行爲。