REST APIとは？

読み方：れすとえーぴーあい

最終更新：2026/08/18

3秒でわかる

URL でリソースを指し HTTP メソッドで操作を表す Web API の設計スタイル。画面側とサーバー側を別々に開発するときの共通ルールになります。

30秒図解

REST APIはusersというリソースをURLで指し、POSTで作成、GETで取得、PATCHで更新、DELETEで削除する状態の変化 — REST APIは、URLとメソッドの組み合わせを共通ルールにします。

もう少し詳しく

どういうものか

REST API は、扱うデータを「リソース」として URL で名指しし、そのリソースに何をするかを HTTP メソッドで表す API の設計スタイルです。ユーザー一覧なら /users、ID が 3 のユーザーなら /users/3 という URL を用意し、取得は GET、作成は POST、更新は PUT や PATCH、削除は DELETE を使います。URL には名詞だけを置き、動作は動詞であるメソッドが担う、という役割分担が REST らしさの中心です。

やり取りするデータの形式は JSON が主流で、サーバーは処理の結果を HTTP ステータスコードで返します。200 が成功、201 が作成成功、400 がリクエスト側の誤り、401 が未認証、404 が対象なし、500 がサーバー側の異常、という対応です。

なぜ必要か

画面側とサーバー側が別チーム、別リポジトリになった時点で、両者は「どの URL にどのメソッドで投げれば何が返るか」だけを頼りに開発を進めることになります。この取り決めが場当たり的だと、/getUser、/user_delete、/updateUserInfo のような命名が増え、一覧を見ても全体像がつかめません。リソースとメソッドという 2 軸に押し込めておくと、新しい機能が増えても URL の形が予測でき、ドキュメントを読まなくても当たりがつきます。

具体例

Express でユーザーリソースを扱う場合の最小構成です。

app.get("/users", (req, res) => res.json(users));
app.get("/users/:id", (req, res) => {
  const user = users.find((u) => u.id === Number(req.params.id));
  if (!user) return res.status(404).json({ error: "not found" });
  res.json(user);
});
app.post("/users", (req, res) => {
  const user = { id: users.length + 1, name: req.body.name };
  users.push(user);
  res.status(201).json(user);
});
app.delete("/users/:id", (req, res) => {
  users = users.filter((u) => u.id !== Number(req.params.id));
  res.status(204).end();
});

同じ URL でも、メソッドが違えば別の処理になります。

つまずきやすいところ

最も多いのは、削除や更新を GET でやってしまう設計です。GET はブラウザやプロキシに「何度呼んでも安全」と見なされるため、先読みやキャッシュで勝手に呼ばれてデータが消えることがあります。次に多いのが、エラーでも 200 を返して本文にエラー内容だけを入れるやり方です。画面側は res.ok で分岐できず、毎回本文を覗く羽目になります。

似た用語との違い

用語	位置づけ
REST API	URL とメソッドでリソースを操作する設計スタイル
GraphQL	単一のエンドポイントに問い合わせ文を送り、必要な項目だけ取る方式
RPC	関数呼び出しをそのまま HTTP に載せる方式。URL が動詞になる