今日のテクノロジー環境において、REST API（Representational State Transfer Application Programming Interface）は、スケーラブルで効率的なWebアプリケーションを構築するための基本的な構成要素となっています。
REST APIは、GET・POST・PUT・DELETEといった標準的なHTTPメソッドを使用してクライアントとサーバー間のコミュニケーションを可能にする、シンプルで統一されたインターフェースです。REST APIは、データ・メディア・コンテンツ・その他のデジタルリソースをWebを通じて提供する優れた手段です。
これらのAPIは、異なるソフトウェアアプリケーション同士がコミュニケーションし、Web上でデータを交換したり処理を実行したりすることを可能にします。
モバイルアプリケーションを構築する場合でも、マイクロサービスアーキテクチャを構築する場合でも、REST APIを活用することでアプリケーションを堅牢かつ柔軟に、顧客のニーズに応えるものにすることができます。
“これらのAPIにより、異なるソフトウェアアプリケーションが互いに連携し、Web上でデータのやり取りや各種処理を行うことができます。”
本記事では、REST APIとは何か、SOAP APIとの比較、そして6つのアーキテクチャ上の制約について解説します。また、RESTが使用される事例とそのメリット・デメリットについても紹介します。
REST APIとは何か？
REST APIの概念をより深く理解するためには、まずAPIとは何かを正確に理解する必要があります。API（Application Programming Interface）とは、異なるソフトウェアアプリケーションが相互にコミュニケーションできるようにするためのルールとプロトコルの集合です。
開発者はアプリケーションが情報のリクエストと交換に使用できるAPIを公開・作成します。APIは、開発者がそれらのシステムの内部動作を知らなくても、アプリケーション・オペレーティングシステム・その他のサービスの特定の機能やデータにアクセスできるようにする抽象的な機能を実現します。
REST APIはAPIの特定の種類であり、REST（ネットワークアプリケーション設計のためのアーキテクチャスタイル）の原則に従うものです。これらのAPIは、ユーザーインターフェース（クライアント）をバックエンドサービス（サーバー）から分離するクライアントサーバーモデルで機能します。
これらのAPIはステートレスであり、クライアント側からの各リクエストがリクエストの理解と処理に必要なすべての情報を含んでいる必要があります。REST APIは通常、JSONやXMLなどの標準的なデータフォーマットを使用します。これらの軽量なフォーマットにより、異なるシステム間の相互運用性が実現します。
最後に、RESTにおける各オブジェクトはリソースとみなされます。それはデータオブジェクトであることもサービスであることもあります。そして各リソースはURI（Uniform Resource Identifier）で識別できます。
REST APIの事例
屋外活動の計画を立てるとき、天気予報を確認する人は多いです。この情報にアクセスするために、モバイルアプリや天気情報サイトが提供するRESTful APIを使用することがあります。
たとえば、ユーザー（クライアント）がスマートフォンの天気アプリを開いて、週末の天気予報を検索するとします。最初のステップとして、アプリは天気サービスのREST APIにリクエストを送信し、特定の場所と日付範囲の予報を求めます。
次にAPIは天気サービスのデータベース（サーバー）から関連データを取得します。最後に、APIは気温・降水量・風速などの情報を含むレスポンスを返します。
ユーザーが天気情報をリクエストするためにRESTful APIを使用できるのと同様に、気象予報士やシステム管理者もこれらのAPIを使用して予報データを更新・変更することができます。
たとえば、急激な天候変化や嵐が接近している場合です。気象予報士はシステム内の気象状況をこの新しい情報を反映するように更新します。するとAPIは更新された気象データをすべてのユーザーに送信し、最新の予報が利用できるようにします。
これらの情報交換をRESTfulたらしめる要素のひとつは、クライアントからリソースのリクエストが行われた後、サーバーがJSONやXMLなどの標準フォーマットでリソースの現在の状態を返す点にあります。
関連記事：さまざまな種類のAPIサービスの概要
REST APIの設計
RESTfulとみなされるためには、APIは以下の6つの設計上の制約に従う必要があります。どのタイプのAPIが組織のニーズに最も適しているかを判断する際に、このアーキテクチャを考慮することが重要です。
“クライアントサーバーアーキテクチャにより、開発者はサーバー側に影響を与えることなくモバイルアプリを変更したり、その逆も可能になります。”
1. クライアントサーバーアーキテクチャ
この制約は、クライアントとサーバーが互いに独立している必要があることを規定しており、どちらかを変更してももう一方に影響を与えないようにします。これにより、たとえばサーバーを変更することなくモバイルアプリを変更することができ、またその逆も可能です。
その結果、RESTful APIはサービスが独立して進化することを可能にし、この分離によって各アプリケーションがスケールでき、最終的には成長と拡張を促進します。
2. ステートレス
すべてのREST APIは、サーバー上の情報に接続されず依存しない、単一で自己完結した情報の表現として存在しなければなりません。
ステートレスの制約のもとでは、安定した継続的なデータストレージを必要とするような（ステートフルな）アプリケーションを繰り返し参照する必要がありません。ステートレスであることにより、サーバーとのインタラクションが減少してエラーの余地が少なくなるため、APIの信頼性が高まります。
3. キャッシュ可能
一定の時間内にデータを保存して再利用する能力は、サーバーへのリクエスト数を減らすことができるため、APIインテグレーションにおいて価値があります。
そのため、RESTful APIはリクエストの増加によって生じるオーバーヘッドを軽減し、クライアントとサーバー間のインタラクションを効率化するためにこの制約を設計に組み込んでいます。
4. 統一インターフェース
RESTful APIは、クライアントとサーバーがHTTP・CRUD・JSONなどの単一の言語でコミュニケーションできる標準化されたインターフェースを必要とします。
この統一インターフェースは、サーバーへのリクエストが個別のリソース（APIがクライアントに提供できる任意の情報）を定義することを要求し、クライアントがサーバー上のリソースに対してアクション（削除または変更）を実行できる機能を提供します。
実行されるアクションは、各リクエストにその処理手順が含まれていなければならないため実現できます。
5. 階層化システム
REST APIは、それぞれが全体に貢献する特定の機能を実行する複数の層で構成されるシステムを必要とします。これらの層は関連するグループに整理され、役割またはアクションの階層に従ってコミュニケーションします。
たとえば、あるシステムでは層Aが層Bにコミュニケーションし、層Bが層Cにコミュニケーションするという形で続いていきます。コミュニケーションチェーン全体が最終的にある結果またはアクションをもたらします。
6. コードオンデマンド（オプション）
コードオンデマンドは唯一のオプション制約です。サーバーからクライアントにコードを送信し、それによってアプリケーションのコード構造を変更してクライアントの機能を拡張する能力のことです。
“クライアントからのリクエストには、そのリクエストを理解・処理するために必要な情報がすべて含まれている必要があります。”
REST APIの仕組み
RESTfulシステムでは、クライアントがサーバーにリクエストを送信します。クライアントからの各リクエストには、リクエストの理解と処理に必要なすべての情報が含まれていなければなりません。サーバーはリクエストを処理して適切なレスポンスを返します。
このレスポンスはJSON（JavaScript Object Notation）、XML（eXtensible Markup Language）、またはHTML（HyperText Markup Language）など様々なフォーマットで返される場合があります。JSONはそのシンプルさとJavaScriptとの使いやすさから最もよく使われるフォーマットです。
また、RESTにおけるすべてのデータはリソースとみなされ、各リソースはユニークなURL（Uniform Resource Locator）で識別されます。サーバーに送信するリクエストの種類は通常メソッドと呼ばれます。主なメソッドには4種類あります。
GETはサーバーから情報を取得するメソッドです。たとえばユーザーデータを取得する場合に使用します。PUTは新しいリソースを作成するためにデータをサーバーに送信するメソッドです。たとえば新しいユーザーをDBに追加する場合に使用します。POSTはサーバー上の既存のリソースを更新するためのメソッドです。たとえばユーザー情報を更新する場合に使用します。DELETEはサーバーからリソースを削除するためのメソッドです。たとえばユーザーグループからユーザーを削除する場合に使用します。
REST APIのHTTPヘッダー
REST APIにおいて、HTTPヘッダーとパラメータはクライアントとサーバーのコミュニケーションを実現するうえで重要な役割を果たします。HTTPリクエストとレスポンスのコンテンツ・構造・動作を定義するのに役立ち、Webサービスが適切に機能していることを確認します。
HTTPヘッダーとは、HTTPリクエストまたはレスポンスとともに送信されるキーと値のペアです。HTTPメッセージに関する関連メタデータを提供し、サーバーとクライアントがリクエストまたはレスポンスをどのように処理するかを理解するのを助けます。
ヘッダーはコンテンツタイプ・認証情報・キャッシュ指示などの情報を提供します。一方パラメータは、URL（クエリパラメータ）またはリクエストボディ（ボディパラメータ）のいずれかを通じてサーバーにデータを送信できます。
リクエストヘッダーとパラメータ
リクエストヘッダーとパラメータには、リクエストの処理方法をサーバーに案内するさまざまな種類の情報が含まれます。主要なリクエストヘッダーのメタデータをいくつか見ていきましょう。
Authorizationはクライアントをサーバーで認証するための認証情報を含みます。Content-Typeはサーバーに送信されるリソースのメディアタイプまたはデータフォーマットを示します。Acceptはクライアントが処理できるメディアタイプを指定し、サーバーが適切なレスポンスフォーマットを返すのに役立ちます。User-Agentはリクエストを行うクライアントソフトウェアに関する情報を提供します。ログ取得とデバッグに役立ちます。Cache-Controlはレスポンスをどのようにどのくらいの期間キャッシュすべきかを指示します。
リクエストパラメータは3つの種類に分類されます。クエリパラメータは?userId=123&sort=ascのように、リソースのフィルタリングやソートのためにGETリクエストのURLに含めて送信されます。パスパラメータは/users/123のように、特定のリソースを識別するためにURLパスの一部として含まれます。ボディパラメータはPOST・PUT・PATCHリクエストのボディ部分に含めて送信され、通常JSONまたはXMLでフォーマットされたリソースの作成や更新に使用されます。
HTTPステータスコード
HTTPヘッダーを理解したところで、HTTPステータスコードについても知っておく必要があります。これらのコードは、HTTPリクエストの結果を示す3桁の数字です。
クライアントのリクエストが成功したか、エラーが発生したかを示す優れた指標です。HTTPステータスコードの主なカテゴリは以下のとおりです。
1xx（情報提供）はリクエストが受信され処理中であることを示します。例：100 Continueです。2xx（成功）はリクエストが正常に受信・理解・受け付けられたことを示します。例：200 OK、201 Createdです。3xx（リダイレクト）はリクエストを完了するためにクライアントがさらなるアクションを取る必要があることを示します。例：301 Moved Permanently、304 Not Modifiedです。4xx（クライアントエラー）はリクエストにエラーがあり処理できないことを示します。例：400 Bad Request、404 Not Foundです。5xx（サーバーエラー）はサーバーが有効なリクエストを処理できなかったことを示します。例：500 Internal Server Error、503 Service Unavailableです。
“リクエストヘッダーがリクエストに関するメタデータを提供するのと同様に、レスポンスヘッダーはレスポンスに関する補足情報を提供します。”
レスポンスヘッダー
リクエストヘッダーがリクエストに関するメタデータを提供するのと同様に、レスポンスヘッダーはレスポンスに関する追加情報を提供します。主要なレスポンスヘッダーには以下のようなものがあります。
Content-Typeはレスポンスボディのメディアタイプを示し、クライアントがデータを正しく解釈するのを助けます。Cache-Controlはno-cacheやmax-ageなどのキャッシュ指示をクライアントに提供します。Set-CookieはサーバーからクライアントにCookieを送信するために使用され、ステートフルなセッションを可能にします。Locationは新しく作成されたリソースのURLを指定し、通常はPOSTまたはPUTリクエストへのレスポンスに使用されます。ETagはリソースの特定のバージョンに対する一意の識別子を提供し、効率的なキャッシュと検証を支援します。
REST APIのメリットとデメリット
WebがRESTful APIで溢れているのには理由があります。実際、理由は一つではなく数多くあります。
まず、RESTの制約内で構築されたAPIは、独立したデータのモジュール型の構成とクライアントとサーバーの分離により、驚くべき柔軟性を持っています。
さらに、複数の種類のコールを処理しXML・JSON・YAMLなどさまざまなフォーマットでコールを返せるAPIの能力により、多くのAPIインテグレーションを収容または処理するシステムに適用するための汎用性の高いアジャイルなアーキテクチャとなります。
柔軟性のもうひとつの特徴は、APIへの変更を行いやすい点です。
REST APIはデータをキャッシュしサーバーとは独立して動作するため、運用に必要な帯域幅が少なくなります。そのため、リソースを消費することなく高いパフォーマンスを発揮します。これは組織のシステムとプロセス全体にわたるスピードと効率の向上につながります。
最後に、アーキテクチャスタイルがシンプルで標準化されているため、開発側のほぼ誰でも理解でき、業界全体で使用・認識されています。これらのメリットが、RESTful APIをクラウドテクノロジーやモバイルアプリケーションに特に適したものにしている理由です。
しかし、スタイルの統一性は理解しやすい一方で、制約の中で構築するという課題があるため、初心者には必ずしも簡単に作成できるわけではありません。
より経験豊富な開発者でも、REST APIが「ステートフルネス」を失う傾向にあり、トラブルシューティングが必要になることに苦労することがあります。これらはAPIの目標を評価する際に考慮すべき重要な点です。
REST APIとSOAP
REST以前、開発者はさまざまなAPIを統合するためにSOAPを扱わなければなりませんでした。SOAPには構築・使用・デバッグにおいて独自の複雑さがありました。そこで次に生まれる論理的な問いは「SOAPとRESTを比べるとどうなのか」ということです。
関連記事：API開発ガイド
SOAPはWebサービスへのアクセスを提供するプロトコルです。RESTはプロトコルではなく、Webサービスへのアクセスに使用されるアーキテクチャスタイルを指します。SOAPとRESTは基本的に同じ機能を実行しますが、それぞれ異なる状況に適しています。
SOAPはXMLを使用したメッセージ構造化のための厳格なルールセットに従うプロトコルです。通常WSDL（Web Services Description Language）を使用して定義される正式なコントラクトが必要で、利用可能な操作と交換されるメッセージの構造を指定します。
SOAPは堅牢性のために設計されており、組み込みのエラーハンドリング・WS-Securityなどのセキュリティ機能・トランザクションサポートを提供し、セキュリティと信頼性が最重要視されるエンタープライズレベルのアプリケーションに適しています。
しかし、RESTと比較したSOAPの複雑さと高いオーバーヘッドは、パフォーマンスの低下と開発工数の増加につながる可能性があります。
“RESTは軽量で、データのやり取りにJSONやXMLといった形式を使用するため、特にWebやモバイルアプリケーションにおいて、高いスケーラビリティと使いやすさを実現しています。”
一方RESTは、GET・POST・PUT・DELETEなどの標準的なHTTPメソッドを活用してCRUD操作を実行するアーキテクチャスタイルです。ステートレスであり、各クライアントリクエストにはサーバーがそれを処理するために必要なすべての情報が含まれている必要があり、リクエスト間でクライアントデータは保存されません。
RESTは軽量でデータ交換にJSONやXMLなどのフォーマットを使用するため、スケーラビリティが高く使いやすく、特にWebおよびモバイルアプリケーションに適しています。
関連記事：APIインテグレーションの7つの事例
まとめ
本記事を読み終えた今、REST APIとは何か、どのように機能するかについて理解できたはずです。REST APIのさまざまなメリットとデメリットについても紹介しました。最後に、RESTとSOAPの詳細な比較もご覧いただきました。
REST APIはさまざまな領域で広く使われていますが、これらのAPIをさらに興味深く効果的なものにするさまざまなツールが登場しています。そのひとつがWorkatoです。インテグレーション主導の自動化のリーダーであるWorkatoは、RESTful APIを使用するアプリコネクタの堅牢なエコシステムを提供しています。
これらのコネクタを使用することで、アプリを統合し、その上でコードを1行も書くことなく、アプリをまたいで機能するワークフロー自動化をWorkatoで構築できます。
Workatoのコネクタライブラリとプラットフォームでできるワークフロー自動化についてさらに詳しく知るために、自動化の専門家との動作デモをリクエストできます。