HTTPとREST API｜基礎を学ぶ - チョットデキル

このレッスンで分かること

HTTP は Web の通信規約。リクエスト + レスポンスの 1 往復

メソッドは GET / POST / PUT / PATCH / DELETE、リソースを CRUD する

ステータスコード ─ 2xx 成功 / 4xx クライアントエラー / 5xx サーバーエラー

REST は「URL = リソース、メソッド = 操作」の設計パターン、JSON が標準

HTTPとREST API とは

HTTPの基本とREST APIの概念を理解しよう。本レッスンでは、HTTPとREST API の基本から実際の使いどころまでを整理し、現場で迷わず使える形に落とし込みます。

HTTPとREST API

Webアプリケーションがサーバーとデータをやり取りするための仕組みを理解しましょう。

HTTPとは

HTTP（HyperText Transfer Protocol） はWebの通信プロトコルです。ブラウザとサーバー間でデータをやり取りするルールを定めています。

HTTPメソッド

データに対する操作の種類をHTTPメソッドで指定します。

メソッド	用途	例
GET	データの取得	ユーザー一覧を取得
POST	データの作成	新しいユーザーを登録
PUT	データの全体更新	ユーザー情報を丸ごと更新
PATCH	データの部分更新	メールアドレスだけ変更
DELETE	データの削除	ユーザーを削除

HTTPリクエストとレスポンス

プレーンテキスト

【リクエスト】
GET /api/users/123 HTTP/1.1
Host: api.example.com
Authorization: Bearer xxxxx

【レスポンス】
HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 123,
  "name": "太郎",
  "email": "taro@example.com"
}

ステータスコード

サーバーはレスポンスにステータスコードを付けて結果を伝えます。

コード	意味	説明
200	OK	成功
201	Created	作成成功
400	Bad Request	リクエストが不正
401	Unauthorized	認証が必要
403	Forbidden	アクセス権がない
404	Not Found	リソースが見つからない
500	Internal Server Error	サーバー内部エラー

ざっくりとした覚え方は次のとおり。

2xxは成功
4xxはクライアント側のエラー
5xxはサーバー側のエラー

REST APIとは

REST（Representational State Transfer） はAPIの設計ルールです。

プレーンテキスト

GET    /api/users        → ユーザー一覧を取得
GET    /api/users/123    → ID:123のユーザーを取得
POST   /api/users        → 新しいユーザーを作成
PUT    /api/users/123    → ID:123のユーザーを更新
DELETE /api/users/123    → ID:123のユーザーを削除

REST APIのルールは以下のとおりです。

URLはリソース（名詞） を表すは/users、/products
HTTPメソッドで操作（動詞） を表すはGET, POST, PUT, DELETE
ステータスコード で結果を伝える
JSON形式 でデータをやり取りする

JSONフォーマット

API通信ではJSON（JavaScript Object Notation） が標準フォーマットです。

JavaScript

// JSONの例
{
  "name": "太郎",
  "age": 25,
  "hobbies": ["読書", "映画"],
  "address": {
    "city": "東京",
    "zip": "100-0001"
  }
}

// JavaScriptでの変換
const obj = { name: "太郎", age: 25 };
const json = JSON.stringify(obj); // オブジェクト → JSON文字列
const parsed = JSON.parse(json);  // JSON文字列 → オブジェクト

実務で遭遇するパターン

中級レッスンで学んだことが、実際の業務コードでどう登場するかを整理します。

SPA とサーバーの通信 ─ ブラウザ JS から fetch("/api/users") でデータ取得
マイクロサービス間 ─ サービス A → B を POST /orders で呼ぶ
サードパーティ API ─ Stripe や Twilio との通信は REST + JSON が定番
Webhook ─ 外部サービスからのイベント通知を POST で受ける

コードレビューで指摘されがちなポイント

PR を出すとシニアから入りやすい指摘です。先回りで身につけておけばレビューが一発で通ります。

動詞を URL に含める ─ /getUsers ではなく GET /users
ステータスコードの誤用 ─ 何でも 200 OK + { error: ... } ではなく適切なコードを返す
PUT と PATCH の混同 ─ 全更新は PUT、部分更新は PATCH
認証ヘッダー漏れ ─ Authorization: Bearer ... を 1 ヶ所に集約してミドルウェアで付与

パフォーマンス考慮事項

HTTP/2 + Keep-Alive ─ TCP コネクション再利用で複数リクエスト高速化
JSON のシリアライズコスト ─ 巨大ペイロードは分割、ストリーミングを検討
キャッシュヘッダー (ETag Cache-Control) ─ GET 結果のキャッシュで API 呼び出しを減らす
並列呼び出し ─ Promise.all で独立リクエストを同時発射

この章のポイント

ここまでの要点 HTTP は要求 / 応答の規約、REST は URL=リソース・メソッド=操作の設計。ステータスコードを正しく使い、PUT / PATCH を区別、認証は集約。

まとめ

HTTPはWeb通信のプロトコル
HTTPメソッド（GET/POST/PUT/DELETE）で操作の種類を指定
ステータスコードで結果を伝える（2xx成功、4xxクライアントエラー、5xxサーバーエラー）
REST APIはURL+HTTPメソッドでリソースを操作する設計パターン
JSONはAPI通信の標準データフォーマット

よくある質問

Q. GET と POST はどう使い分けますか？

A. 「取得して副作用がない」なら GET、「作成・更新など状態を変える」なら POST が原則です。GET は URL にパラメータが入りキャッシュも効きますが、POST はボディに乗せられ大きなデータも送れます。冪等性も GET は持ち、POST は持たないという違いがあります。

Q. ステータスコードは何を返すべき？

A. 成功は 2xx、リダイレクトは 3xx、クライアントエラーは 4xx、サーバーエラーは 5xx が大原則です。新規作成は 201、認証失敗は 401、権限不足は 403 を返すと REST 慣習に沿った設計になります。200 で全部返すのは避けてください。

Q. REST と GraphQL の違いは？

A. REST はリソース単位のエンドポイント、GraphQL は単一エンドポイントでクエリ言語を使って欲しいデータを指定します。フロントの要件が頻繁に変わるなら GraphQL、シンプルな CRUD なら REST がメンテしやすいことが多いです。

次のレッスン

次は fetch APIの基本 で、HTTPの基本とREST APIの概念を理解しようを学びます。

事前確認 — 進む前に次の 3 つができることを確認しましょう。

HTTPとREST API の要点を自分の言葉で説明できる
このレッスンの最小コード (または操作手順) を見ずに書ける
練習問題やクイズで間違えた箇所を読み直して理解した

理解度チェック (30 秒)

Q. HTTPとREST API とは何か、1 文で説明してください。

この章のポイント

A. 本文の「このレッスンで分かること」または冒頭の説明文を見直し、自分の言葉で要約できれば OK。詰まったら本レッスンの最初の H2 セクションを読み返してみましょう。

関連レッスン