REST APIの設計原則

Node.jsを用いた「API開発とREST設計」におけるREST APIの設計原則について、以下のように詳しく説明します。


REST APIとは

REST(Representational State Transfer)は、Webサービス設計のアーキテクチャスタイルです。RESTに従ったAPIは、HTTPのメソッドとURLの構造を用いて、リソース(データ)への操作を統一的に表現します。


REST APIの設計原則

1. リソース指向の設計

  • データは「リソース」として捉えます。

  • リソースは名詞で表現し、**エンドポイント(URL)**で識別します。

    • 例:

      • /users(ユーザーの一覧)

      • /users/123(ID=123のユーザー)

2. HTTPメソッドの適切な使用

リソースに対する操作は、HTTPメソッドで表現します。

メソッド 用途 説明
GET 読み取り リソースの取得
POST 作成 新しいリソースの作成
PUT 更新 リソース全体の更新
PATCH 部分更新 リソースの一部のみを更新
DELETE 削除 リソースの削除

3. ステータスコードの適切な返却

HTTPステータスコードは、APIの処理結果を明確に表す必要があります。

ステータスコード 意味
200 OK 正常に処理完了(GETなど)
201 Created 新規作成成功(POSTなど)
204 No Content 成功したが返すデータなし(DELETEなど)
400 Bad Request リクエストの内容が不正
401 Unauthorized 認証失敗
403 Forbidden 権限なし
404 Not Found リソースが見つからない
500 Internal Server Error サーバ内部エラー

4. 階層的なURL設計

リソースの関係をURL構造で表現します(親子関係を示す)。

  • 例:

    • /users/123/posts → ユーザー123の投稿一覧

    • /users/123/posts/456 → ユーザー123の投稿ID=456

5. ステートレス(状態を持たない)

  • 各リクエストは独立して処理されるべきで、サーバ側はセッション情報を保持しない

  • クライアントは必要な認証情報(例:トークン)を毎回送信する。

6. 一貫性のあるレスポンス形式

  • JSONが主に使用され、構造は統一する。

  • 例(ユーザー情報):

    json
    { "id": 123, "name": "Taro", "email": "taro@example.com" }

7. エラーレスポンスも構造化

  • エラー内容はクライアントが解釈しやすいように構造化して返す。

例:

json
{ "error": "InvalidRequest", "message": "Email is required" }

8. バージョニング

  • 変更に備えてAPIにバージョンを設ける。

  • URLでの表現が一般的(例:/api/v1/users


補足:RESTfulな設計とは

REST APIの設計原則に忠実に従うことを「RESTful(レストフル)」と呼びます。RESTfulな設計を採用することで、理解しやすく保守しやすいAPIを実現できます。

ChatGPT4o 生成日:2025/06/25