Restful API
HTTPプロトコル（GET/POST/PUT/DELETE）を用いて、URLで識別されたWeb上のリソース（データ）を操作する設計原則（REST）に準拠したAPIです。
ステートレス（状態を持たない）で軽量なため、モダンなWebサービスやモバイルアプリのバックエンド通信で標準的に利用されています。
HTTPメソッドのマッピング
REST/RESTfulでは遵守することを求められていませんが、基本、遵守必須と考えておきましょう。
| HTTPメソッド | CRUD | 操作内容 |
|---|---|---|
| GET | R | リソース(データ)の取得 |
| POST | C | リソース(データ)の作成 |
| PUT/PATCH | U | リソース(データ)の更新 |
| DELETE | D | リソース(データ)の削除 |
リソース(データ)の取得については例外があります。
HTTPのGETメソッドには、実装上の制約によるURI(URL)の長さ制限があるため、検索条件が多く、クエリ・パラメータが極端に長くなる場合、POSTメソッドで代替して制限を回避します。
CRUD
データベースの基本的な4つの操作機能の総称です。
ほぼ全てのアプリやシステムでデータ管理に必須の基礎概念です。
| 機能 | SQL | |
|---|---|---|
| Create | INSERT | 登録(作成) |
| Read | SELECT | 参照 |
| Update | UPDATE | 更新 |
| Delete | DELETE | 削除 |
HTTPステータス・コードのマッピング
HTTPステータスコードを用いて処理結果（成功、失敗、エラーの種類）をクライアントに明確に伝えることが重要です。
エラーの種類とHTTPステータス・コードを正しくマッピングする(エラーの種類に応じて適切なHTTPステータスコードを選択する)必要があります。
REST/RESTful APIでは、規定(標準化)されていませんが、このマッピングはRESTful APIの設計において重要です。
作成するアプリやシステムにおいて、マッピングをきちんと定義しルール化し遵守することで、コードの見通しが良くなるとともに、エラーまわりの処理(分岐)の共通化が可能になります。
世の中に存在するアプリやシステムの中には、このマッピングを正しく行えていないシステムがそれなりに存在します。
例えば、バリデーション・エラーの場合、ステータス・コードとして422を返すべきなのですが、正常終了扱いで200を返している等です。
| ステータス・コード | 名前 | ||
|---|---|---|---|
| 200系 | - | 正常終了 | - |
| 200 | OK | - | レスポンスボディを返す場合 |
| 201 | Created | - | POSTなどで新しいリソースが正常に作成された場合 |
| 204 | No Content | - | レスポンスボディを返さない場合 |
| 300系 | - | リダイレクト | - |
| 303 | See Other | - | レスポンスが他のURIとして存在し、リダイレクトする場合 |
| 400系 | - | クライアント・エラー | - |
| 400 | Bad Request | - | 不正なリクエスト(サーバーがリクエストを理解できない場合) |
| 401 | Unauthorized | - | 未認証 or 認証失敗 |
| 403 | Forbidden | - | 認証済みでアクセス権限なし |
| 404 | Not Found | - | リソース未検出(不在) |
| 409 | Conflict | - | リソース競合 |
| 422 | UNPROCESSABLE CONTENT(旧UNPROCESSABLE ENTITY) | - | バリデーション・エラー |
| 500系 | - | サーバー・エラー | - |
| 500 | INTERNAL SERVER ERROR | - | サーバー内部エラー |
| 503 | SERVICE UNAVAILABLE | - | サービス利用不可 |
※ 201(Created)については、(ほとんどの場合)200(OK)で問題ないはずです。
参考