RESTful API設計におけるHTTPステータスコードの指針 - Qiita

RESTful APIを設計した際のステータスコードの指針です。 メソッド別 GET 成功した場合 200 OK：最も一般的 304 Not Modified：条件付きGETでキャッシュを使わせたい場合 POST 成功した場合 201 Created 作成したリソースのURIを示すLocationヘッダを付けておく 議論 200 OKだとまずいのか？ 200 OKを応答する実装も多くあり、まずいというわけでもない 200 OKはPOST結果がキャッシュ可能、201 CreatedはPOST結果がキャッシュ不可能として分けてもいいが、そこまでする必要があるか？（POSTのキャッシュは一般的ではない） 204 No Contentだとまずいのか？ クライアントがPOST結果を事前に全て知っているわけではないのでNo Contentは不親切では？ 失敗した場合 409 Conflict：作成しよ

[hirorock]

httpステタースコード REST

[nkgr]

バグの時ヒントが適切な値がかえると予測しやすい

[gonta616]

ふむふむ

[kojiro-s]

参考になる

[ginpei]

メソッドと処理結果によって応答ステータスコードを決める。「議論」も載ってるの嬉しい。

[kitokitoki]

http status code「RESTful API設計におけるHTTPステータスコードの指針」