雖然我不是微軟派的，但是不得不說他們文件寫得真是認真
https://docs.microsoft.com/zh-tw/azure/architecture/best-practices/api-design
好入手，廣度，深度也都有一定程度的水準

你貼的這篇就建議404啊

找不到資源!=沒資料

這篇是說要回傳204

用ID Get的時候找不到資源的情況是404吧

大家熱烈討論還蠻棒的，資源不存在跟沒有結果是細微的不同

原來正解是204 ...

照這篇就是要404阿...資源不存在不就是找不到資料（e.g.資料庫沒這筆資料）204是指說找到這筆資料，但是內容是空的

這篇並不是說要回傳204「未包含任何 respose 主體」並不是「未包含任何資料」

for example, a search operation yielding no matchesmight be implemented with this behavior.

喔沒事 我切到英文版了 當我沒說（這篇建議用204

不過我覺得是如果想要回傳是 {} 空陣列, 那就是 200如果要直接表示沒有要回傳的東西, 就用 204

我個人不建議204的原因是，要是客戶端一律把回傳值先拿去parse成json，那204或200不帶訊息都會出錯

客戶一律parse json那是客戶不看使用說明的問題？GetById和search應該是不同的操作

search operation和resource是兩回事

你可以說是客戶的問題 你也可以減少客戶的犯錯空間

什麼叫做resource，什麼叫operation上面的段落有寫有些實作沒辦法對應成資源的，可以把這種「非資源」的作業公開成虛擬資源，如/add?operand1=99&operand2=1簡單說， /名詞/{id} 這種找不到應該用404動詞?參數={value1}&參數={value2} 這種才是找不到時可以用204的

承樓上說的，要根據 RESTful 的設計應該盡量避免 URL 帶有動詞的操作。可以在頁面的 route 上出現 login，但呼叫後端時，登入的操作是要獲取 resource（以這種情景通常資源會命名為 session

更正一下，應該說作業結果是沒結果時用204，找不到還是404

這麼明確的東西我不覺得是減少客戶犯錯空間。

404 無法表達是網址錯 還是沒資源

用path parameter 的方式就回404，不是的話就用body回空array 然後200

不懂的人去看國際標準： RFC2616。4xx開頭是 error 。2xx開頭是 Info。

要看也是看 2014 後更新調整的 RFC7231，這個版本才把 REST風格考慮進去，敘述中多了對表現層（representation）的解釋

其實就在這個月出了RFC9110 XD

RFC9110 針對 Status Code 的敘述跟 RFC7231 沒有太多差異