作者:
yfr 2022-06-22 15:17:49雖然我不是微軟派的，但是不得不說他們文件寫得真是認真
https://docs.microsoft.com/zh-tw/azure/architecture/best-practices/api-design
好入手，廣度，深度也都有一定程度的水準
作者:
ssccg (23)
2022-06-22 15:28:00你貼的這篇就建議404啊
作者: xup6y3ru04 (奇奇奇奇奇) 2022-06-22 16:17:00
這篇是說要回傳204
作者: s06yji3 (阿南) 2022-06-22 16:25:00
用ID Get的時候找不到資源的情況是404吧
作者:
yfr 2022-06-22 16:30:00大家熱烈討論還蠻棒的，資源不存在跟沒有結果是細微的不同
作者:
crazycy (LCY)
2022-06-22 17:01:00照這篇就是要404阿...資源不存在不就是找不到資料（e.g.資料庫沒這筆資料）204是指說找到這筆資料，但是內容是空的
作者:
Romulus (Säubern Mode)
2022-06-22 17:03:00這篇並不是說要回傳204「未包含任何 respose 主體」並不是「未包含任何資料」
作者: iterator (rotareti) 2022-06-22 17:04:00
for example, a search operation yielding no matchesmight be implemented with this behavior.
作者:
Romulus (Säubern Mode)
2022-06-22 17:05:00喔沒事 我切到英文版了 當我沒說（這篇建議用204
作者: iterator (rotareti) 2022-06-22 17:05:00
不過我覺得是如果想要回傳是 {} 空陣列, 那就是 200如果要直接表示沒有要回傳的東西, 就用 204
作者:
Romulus (Säubern Mode)
2022-06-22 17:07:00我個人不建議204的原因是，要是客戶端一律把回傳值先拿去parse成json，那204或200不帶訊息都會出錯
作者: s06yji3 (阿南) 2022-06-22 17:11:00
客戶一律parse json那是客戶不看使用說明的問題？GetById和search應該是不同的操作
作者:
ssccg (23)
2022-06-22 17:15:00search operation和resource是兩回事
作者:
Romulus (Säubern Mode)
2022-06-22 17:17:00你可以說是客戶的問題 你也可以減少客戶的犯錯空間
作者:
ssccg (23)
2022-06-22 17:17:00什麼叫做resource，什麼叫operation上面的段落有寫有些實作沒辦法對應成資源的，可以把這種「非資源」的作業公開成虛擬資源，如/add?operand1=99&operand2=1簡單說， /名詞/{id} 這種找不到應該用404動詞?參數={value1}&參數={value2} 這種才是找不到時可以用204的
作者:
Hsins (翔)
2022-06-22 17:25:00承樓上說的，要根據 RESTful 的設計應該盡量避免 URL 帶有動詞的操作。可以在頁面的 route 上出現 login，但呼叫後端時，登入的操作是要獲取 resource（以這種情景通常資源會命名為 session
作者:
ssccg (23)
2022-06-22 17:27:00更正一下，應該說作業結果是沒結果時用204，找不到還是404
作者: s06yji3 (阿南) 2022-06-22 17:27:00
這麼明確的東西我不覺得是減少客戶犯錯空間。
作者:
Jichang (C.C.Lemon)
2022-06-22 18:17:00404 無法表達是網址錯 還是沒資源
用path parameter 的方式就回404，不是的話就用body回空array 然後200
作者:
DrTech (竹科管理處網軍研發人員)
2022-06-23 08:30:00不懂的人去看國際標準： RFC2616。4xx開頭是 error 。2xx開頭是 Info。
作者:
Hsins (翔)
2022-06-23 08:33:00要看也是看 2014 後更新調整的 RFC7231，這個版本才把 REST風格考慮進去，敘述中多了對表現層（representation）的解釋
作者:
Romulus (Säubern Mode)
2022-06-23 09:24:00其實就在這個月出了RFC9110 XD
作者:
Hsins (翔)
2022-06-23 09:25:00RFC9110 針對 Status Code 的敘述跟 RFC7231 沒有太多差異