RESTful APIのHTTPステータスコード設計 - Qiita
RESTfulなAPIでは、以下の理由によりAPIの処理結果は適切なHTTPステータスコードを利用することが推奨されている。 適切なHTTPステータスコードを返さないと、レスポンスボディの中身を解析して処理結果を判定する必要がある HTTPの標準仕様を使うことで、HTTPステータスコードから処理結果を判定することができる HTTPの標準仕様を使うことで、APIを利用する第三者にとっても理解しやすくなりバグの混入を減らすことができる ほとんどのHTTPクライアントライブラリはHTTPステータスコードを見てリクエストが成功したか、失敗したかを判別している ※ステータスコードは一律200で処理結果をレスポンスボディで表現するようなことはしてはいけない。例えば、API側で内部エラーが発生し本来であれば500(INTERNAL SERVER ERROR)を返さなければいけないところを、200で返して
綺麗なAPIを設計するには気をつけたい5つのポイント | NTT Communications Developer Portal
綺麗なAPIとは開発者にとって理解しやすく、使いやすいAPIです。さらに提供側にとってはメンテナンスしやすく、拡張性も担保されたものになります。そうしたAPIを設計するのは容易ではありませんが、幾つかのルールを設けておくことでも十分に綺麗に設計できるようになるでしょう。 1. モデル型かアクション型か URLを設計する際にRESTfulに作るのがデファクトになっていますが、その中でもURLの作り方をモデル（ユーザ、商品など）にするか、アクション型（購入する、出席するなど）にするかで分かれます。どちらを採用するにしても明確な基準が必要です。両方を満遍なく取り入れると、非常に分かりづらいものになります。 一般的には GET /users/1 でユーザデータに対する操作であるといった形にします。つまりモデル型です。 となると POST /purchase で購入するというアクションを定義するより
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
