メシのタネ

めしのたねになるIT情報配信サイト


RESTってつまり何?Webエンジニアが悩まないためのAPI設計入門

,

  1. API
  2. RESTってつまり何?Webエンジニアが悩まないためのAPI設計入門

Web APIを作ろうとしたとき、こんな疑問にぶつかったことはありませんか?

  • POSTとPUTって、どう違うの?
  • ユーザーを削除するURLって /deleteUser でいいの?
  • ステータスコードって、200以外に何使えばいいの?

APIを設計していると、こうした“地味だけど重要”なポイントで迷うことがよくあります。

実はこういった迷いの多くは、「どんなルールでAPIを設計するのか?」 がはっきりしていないことが原因だったりします。

そこで登場するのが、REST(レスト) という設計思想です。

あまり聞き慣れない言葉かもしれませんが、実は私たちが普段使っている多くのWebサービスは、RESTの考え方をベースに作られています。

Laravel、Spring、Railsなど、使っているフレームワークに関係なく、RESTの基礎を知っておくと「API設計で迷わない軸」ができます。

本記事では、これからAPIを設計・実装しようとしている人向けに、

  • RESTってそもそも何?
  • URLやHTTPメソッド、どう使い分ければいい?
  • ステータスコードの選び方ってあるの?

といったポイントを、わかりやすく&実例を交えて 解説していきます。

RESTとは?Webの設計を支える“考え方”

REST(レスト)は、2000年にロイ・フィールドイング(Roy Fielding)が博士論文 『Architectural Styles and the Design of Network-based Software Architectures』 の中で提唱した、Webアーキテクチャに関する設計思想です。

論文全文はこちら(英語): https://ics.uci.edu/~fielding/pubs/dissertation/top.htm

RESTはいわゆる「APIの仕様」や「技術」ではなく、“どう設計すればWebサービスは拡張性が高く、わかりやすくなるか?”というアーキテクチャスタイルのひとつです。

RESTの6つの設計原則(ざっくり要点)

  • 統一インターフェース:APIの使い方が一貫していて学習コストが低い
  • クライアント・サーバ:役割分離で柔軟な開発が可能に
  • ステートレス:リクエストは毎回独立して完結
  • キャッシュ可能:応答にキャッシュ可否を明示できる
  • 階層構造:中間サーバやゲートウェイを意識した構成が可能
  • コードオンデマンド(任意):必要に応じてコードを送る仕組み(JSなど)

リソースとHTTPメソッド:正しいURL設計とは?

RESTの考え方では、URLは“リソース(=データ)を表す名詞”として設計するのが基本。

そして、そのリソースに対して何をするのかは、HTTPメソッド(GET、POST、PUTなど)で表現します。

典型的なREST設計の例:

メソッドエンドポイント意味
GET/usersユーザー一覧の取得
GET/users/123特定ユーザーの取得
POST/users新しいユーザーの作成
PUT/users/123ユーザー情報の全体更新
PATCH/users/123ユーザー情報の一部更新
DELETE/users/123ユーザーの削除

RESTではURLは「操作の対象(=リソース)」を示し、 「どんな操作をするのか」はHTTPメソッドで表現します。 URLが“名詞”、HTTPメソッドが“動詞”の役割を担う、という考え方です。

このルールを守ることで、エンドポイントが直感的で読みやすくなり、他の開発者とのコミュニケーションもスムーズになります。


現実世界のAPI設計:カスタムメソッドという選択肢

REST原則に従って設計していても、標準的なCRUD操作では表現しにくい処理もあります。

たとえば:

  • ユーザーのアクティベーション
  • アカウントの一時停止

Googleのカスタムメソッド

POST /users/{id}:activate
POST /users/{id}:suspend

これはRESTの”名詞+HTTPメソッド”という原則からは外れますが、 **「わかりやすく、意図が明確に伝わる」**という点で非常に実用的です。

📚 Google Cloud API Design Guide

他にも同様の例は多数

  • GitHub API:POST /repos/:owner/:repo/merges
  • Microsoft Graph API:POST /me/sendMail
  • Stripe API:全てPOSTで処理(例:/subscriptions/{id}/cancel

大事なのは、REST原則を理解したうえで「意図的に」例外を作ることです。

HTTPステータスコードの意味、ちゃんと使えてる?

ステータスコードは、APIが「何を返すか」だけでなく「どう返すか」を示す大事なパーツです。

コード意味使用例
200OK(成功)通常の成功レスポンス(GETなど)
201Created(作成成功)リソースが新しく作成された(POST)
204No Content(内容なし)成功だが返すデータがない(DELETEなど)
400Bad Request(リクエスト不正)パラメータ不足、形式不正など
401Unauthorized(認証エラー)トークン未付与、期限切れなど
403Forbidden(アクセス拒否)権限不足、アクセス不可
404Not Found(見つからない)指定したリソースが存在しない
409Conflict(リソース競合)すでに存在する、重複チェックなど
422Unprocessable Entity(処理不能)バリデーションエラーなど入力エラー
500Internal Server Errorサーバー内部のエラー(バグなど)
503Service Unavailableサーバーメンテ中や過負荷など

RESTでは、ステータスコードも「リソースの状態変化を表現する手段」として使われます。


REST設計は“原則”と“現実”のバランスが大事

RESTの原則を学ぶことは、API設計において大きな武器になります。

ただし、原則に固執しすぎて設計が複雑になってしまっては本末転倒です。

  • 基本は「リソース×HTTPメソッド」の組み合わせ
  • でも、伝わりやすさや業務要件を重視するなら、柔軟に“逸脱”することもアリ
  • ステータスコードや冪等性など、HTTPの基礎もRESTの一部として理解する

RESTは“設計の指針”であり、“チェックリスト”ではありません。 あなたのAPIが、「使いやすく、意図が伝わる」ものになっていれば、それはきっとREST的です。


コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

This site uses Akismet to reduce spam. Learn how your comment data is processed.

若い頃、「仕事中にハマったこと」や「誰かに共有したい技術的な気づき」をアウトプットしたくてブログを始めましたが、勢い任せでよく分からない記事を大量生産し、あえなく飽きて終了。

改めて今、キャリア15年分の経験や知識が、これからITエンジニアを目指す方や、同じような課題で悩んでいる現役エンジニアの「メシのタネ」になるような記事を残したいと思っています。
※過去の記事は見ると精神が崩壊するため、そっとしておいてください。

🛠 経歴という名の珍道中:
文系Fラン → 広告営業 → Web営業 → 通信営業 → Web進行 → 出版 → Web媒体運用 → ソフトウェアハウス → SES → フリーランス

専門教育も受けず、転職歴も多数。履歴書はまるで時系列の事故記録のようですが、試行錯誤を重ね、なんとかエンジニアとして食べています。

このブログでは、そんな「履歴書クラッシャー型エンジニア」が送る、
名古屋一敷居の低い、実務に役立つ技術ブログを目指します。

Laravel
Laravel Eloquent sync 系メソッド完全攻略 — 安全な同期のための 5 大リスクと回避策New!!
Laravel
belongsToMany 実戦ガイド ── “withPivot”で追加カラムを守る 中間テーブル設計チェックリストNew!!
PHP
魔王と行く! / Interface / Polymorphism / Ontology 深淵ガイドNew!!
Laravel
Laravel 12、「コード 1 行も書き換えず未来へ」──静かな革命の手順書New!!
Laravel
LaravelのMiddlewareって意味あるの?仕組み・使いどころ・やらかしまで整理してみた
Laravel
ServiceProviderって何してるの?DIの背後で動いてるやつの正体