REST APIとは？6つの原則・HTTPメソッド・設計の考え方を実務目線で解説
別記事「APIとは？非エンジニアにもわかるビジネス活用のポイント」では、APIそのものの考え方や企業での活用場面を紹介しました。今回は、現在公開されているWeb APIの多くが採用している設計方式「REST API」に焦点を当て、外部ベンダーとの打ち合わせで実際に使える程度まで、具体的なルールを整理します。
RESTとは何か：提唱者と6つの制約
REST（Representational State Transfer）は、コンピューター科学者のRoy Fielding氏が2000年に発表した博士論文「Architectural Styles and the Design of Network-based Software Architectures」の中で提唱した、Web APIの設計スタイルです。
この論文では、RESTらしい（RESTfulな）設計であるための制約として、次の6つが挙げられています。
- クライアント・サーバー：画面側（クライアント）とデータ処理側（サーバー）の役割を分離する
- ステートレス：サーバー側は、リクエストごとの状態（ログイン状態など）を保持しない。各リクエストに必要な情報はそのリクエスト自体に含める
- キャッシュ可能性：レスポンスをキャッシュ（一時保存）してよいかどうかを明示できる
- 統一インターフェース：URLとHTTPメソッドの組み合わせで、リソース（データ）の操作方法を統一的に表現する
- 階層化システム：クライアントは、直接サーバーとやり取りしているのか、間に別のサーバー（ロードバランサー等）が挟まっているのかを意識しなくてよい
- コードオンデマンド（任意）：サーバーがクライアント側で実行するプログラムを送り込める、という制約。ほとんどのWeb APIでは採用されていない任意項目
厳密には、この6つ全てを満たす設計だけが「RESTful」と呼べますが、実務では「ステートレスで、URLとHTTPメソッドでリソースを操作する設計」程度の緩い意味で「REST API」という言葉が使われていることも多い、という実情も知っておくとよいでしょう。
HTTPメソッドと「べき等性」という実務で重要な概念
REST APIでは、次のHTTPメソッドを使ってリソースへの操作を表現します。
| メソッド | 意味 | べき等性 |
|---|---|---|
| GET | データの取得 | べき等 |
| POST | 新規データの作成 | べき等でない |
| PUT | データ全体の置き換え | べき等 |
| PATCH | データの一部更新 | べき等でない |
| DELETE | データの削除 | べき等 |
ここで登場する「べき等性（idempotency）」は、多くの解説記事が説明を省略しがちですが、実務上とても重要な概念です。
べき等とは、「同じリクエストを何度送っても、結果が変わらない」という性質のことです。
例えば、通信が不安定でリクエストが正常に届いたか分からず、念のためもう一度同じリクエストを送るという場面を考えてみましょう。
DELETE（削除）であれば、2回送っても「削除された状態」のままなので問題ありません。
しかしPOST（新規作成）が べき等でないメソッドの場合、同じリクエストを2回送ると、同じデータが重複して2件作成されてしまう可能性があります。
外部ベンダーとAPI連携の仕様を確認する際は、「このAPIはリトライしても大丈夫か（べき等か）」を確認しておくと、二重登録などのトラブルを防げます。
覚えておきたいステータスコードの実務的な意味
REST APIのレスポンスには、処理結果を表す「ステータスコード」が付きます。代表的なものは次のとおりです。
| コード | 意味 |
|---|---|
| 200 OK | 正常に処理が完了した |
| 201 Created | 新規データの作成に成功した |
| 204 No Content | 処理は成功したが、返すデータがない（削除成功時等） |
| 400 Bad Request | リクエストの内容に不備がある |
| 401 Unauthorized | 認証情報が不足・無効 |
| 403 Forbidden | 認証はできているが、その操作を行う権限がない |
| 404 Not Found | 指定したデータ（リソース）が存在しない |
| 429 Too Many Requests | 短時間にリクエストを送りすぎて制限にかかった |
| 500 Internal Server Error | API提供側のサーバー内部でエラーが発生した |
この中で、企業のAPI連携において実務上つまずきやすいのが「429 Too Many Requests」です。
多くのAPIには「1分間に〇回まで」「1日あたり〇回まで」といった呼び出し回数の上限（レート制限）が設けられており、これを超えると429エラーが返されます。
連携システムを開発・導入する際は、想定する利用頻度がAPI提供元のレート制限内に収まるか、事前に確認しておくことが望ましいです。
REST API・SOAP・GraphQLの違いと使い分け
API連携の話をしていると、REST以外に「SOAP」や「GraphQL」という言葉が出てくることがあります。それぞれの特徴を整理すると次のようになります。
| 方式 | 特徴 | 主な採用場面 |
|---|---|---|
| REST | URLとHTTPメソッドでシンプルに表現。実装が容易でエコシステムが広い | 一般的なWeb API・SaaS連携の主流 |
| SOAP | XMLベースの厳格なプロトコル。仕様が細かく規定されている | 金融・医療など、高い信頼性・標準化が求められる分野で採用例が多い |
| GraphQL | 単一のエンドポイントに対し、クライアント側が必要なデータの形を指定して取得できる（2012年Facebook社内開発、2015年オープンソース化） | 画面ごとに必要なデータの形が大きく異なる、大規模なアプリケーション |
中小企業が外部サービスと連携する場合、選択肢はREST API一択であることがほとんどです。SOAPやGraphQLへの深い理解が必須になる場面は限定的ですが、「なぜこの連携先はSOAPを使っているのか（レガシーな金融系システムだから、等）」を理解しておくと、ベンダーとの会話がスムーズになります。
REST API利用時の認証方式
REST APIを呼び出す際は、多くの場合「誰が呼び出しているか」を確認するための認証が必要です。代表的な方式は次のとおりです。
- APIキー：発行された1つの文字列をリクエストに含めるだけのシンプルな方式。実装は容易だが、漏えいした場合の影響が大きい
- OAuth2.0：利用者本人の同意（認可）に基づき、第三者のアプリに限定的な権限を付与する仕組み。「〇〇と連携する」ボタンを押すとログイン画面に飛ぶ、といった体験の裏側で使われている
- JWT（JSON Web Token）：認証情報をトークン自体に埋め込む方式。サーバー側で毎回セッション情報を保持しなくてよいため、前述のステートレスな設計と相性がよい
銀行APIのように高いセキュリティが求められる連携ではOAuth2.0が採用されることが多く、社内システム間の単純な連携ではAPIキーで済ませているケースも少なくありません。
日本国内のREST API公開実例
国内では、全国銀行協会（全銀協）が主導する形で、各銀行が「参照系API」（残高照会・入出金明細照会）と「更新系API」（振込・振替）をREST形式で公開する取り組みが進められてきました。
国内では2017年5月にメガバンクが初の参照系APIを、2018年2月に更新系APIの提供を開始しています。
ネット銀行の中では、GMOあおぞらネット銀行が2019年に参照系・更新系の両APIを公開し、開発者向けポータルで仕様を公開、200社を超える事業者が接続する規模まで拡大しています。
業務システムの分野でも、サイボウズのkintoneやfreeeが、それぞれREST形式のAPIを公開しており、外部の会計ソフトやノーコードツールとの連携の土台になっています。
非エンジニアがベンダーとの会話で押さえておきたいポイント
実際に外部ベンダーとAPI連携の話をする際、非エンジニアの立場でも次の点を確認できると、後のトラブルを減らせます。
- そのAPIはRESTか、それとも別方式（SOAP等のレガシーな仕組み）かを確認する
- 連携したい操作（データの取得・更新・削除等）に対応するAPIが用意されているかを確認する
- 1分・1日あたりのリクエスト回数の上限（レート制限）と、自社の想定利用頻度が収まるかを確認する
- 認証方式（APIキー・OAuth2.0等）と、キーやトークンの管理をどちらが担当するかを確認する
また、IPA（情報処理推進機構）の「API標準設計ガイド」やデジタル庁の「APIテクニカルガイドブック」でも、認証・認可・レート制御をAPIゲートウェイ等で一元管理することの重要性が示されています。自社でAPIを新たに公開する側になる場合は、こうした公的機関の資料も参考にするとよいでしょう。
よくある質問
Q. RESTfulでないAPIも「REST API」と呼ばれることはありますか？
実務上はよくあります。
Fieldingの6つの制約を厳密に全て満たしていなくても、「URLとHTTPメソッドでリソースを操作する、JSON形式のAPI」という程度の意味で「REST API」と呼ばれているケースが多く見られます。
Q. べき等性が保証されていないPOSTリクエストで、二重送信を防ぐにはどうすればよいですか？
API側が「冪等性キー（Idempotency-Key）」と呼ばれる仕組みに対応している場合、リクエストごとに一意な識別子を付与することで、同じリクエストが複数回届いても1回分の処理として扱ってもらえることがあります。
対応の有無はAPI提供元の仕様書で確認する必要があります。
Q. 429エラーが頻発する場合、どう対処すればよいですか？
リクエストの頻度を減らす、複数のリクエストをまとめて送れるAPI（バルクAPI）が用意されていればそちらに切り替える、API提供元に上限緩和のプランがないか問い合わせる、といった対処が考えられます。
参考にした主な調査・資料
- Roy T. Fielding「Architectural Styles and the Design of Network-based Software Architectures」（2000年博士論文 Chapter 5）
- MDN Web Docs：Idempotent
- MDN Web Docs：HTTPステータスコード
- IBM：GraphQL vs REST API
- 全国銀行協会：オープンAPIの取り組みに関する記事
- GMOあおぞらネット銀行：開発者ポータル
- cybozu developer network：kintone REST API
- IPA「API標準設計ガイド・基礎編」
まとめ
REST APIは、URLとHTTPメソッドでリソースを操作するシンプルさから、現在のWeb API連携の主流となっている設計方式です。
特に「べき等性」と「レート制限（429エラー）」は、実際のAPI連携で問題になりやすいポイントであり、非エンジニアであっても押さえておくと、外部ベンダーとの会話や仕様確認がスムーズになります。
APIの基礎的な考え方については、別記事「APIとは？非エンジニアにもわかるビジネス活用のポイント」もあわせてご覧ください。
