Representational State Transfer (REST) は、API の動作に条件を課すソフトウェアアーキテクチャです。REST は当初、インターネットなどの複雑なネットワークでの通信を管理するためのガイドラインとして作成されました。REST ベースのアーキテクチャを使用して、大規模で高性能で信頼性の高い通信をサポートできます。簡単に実装および変更できるため、あらゆる API システムに可視性とクロスプラットフォームのポータビリティをもたらします。 API デベロッパーは、いくつかの異なるアーキテクチャを使用して API を設計できます。REST アーキテクチャスタイルに従う API は、REST API と呼ばれます。REST アーキテクチャを実装するウェブサービスは、RESTful ウェブサービスと呼ばれます。RESTful API という用語は、通常、RESTful web API を指します。ただし、REST API と RESTful API という用語は同じ意味で使用できます。以下は、REST アーキテクチャスタイルの原則の一部です。統一されたインターフェイス統一されたインターフェイスは、RESTful ウェブサービスの設計の基本であり、サーバーが標準形式で情報を転送することを示します。フォーマットされたリソースは、REST では「表現」と呼ばれます。この形式は、サーバーアプリケーション上のリソースの内部表現とは異なる場合があります。例えば、サーバーはデータをテキストとして保存できますが、HTML 表現形式で送信します。統一されたインターフェイスは、次の 4 つのアーキテクチャ上の制約を課します。リクエストはリソースを特定する必要があります。これは、Uniform Resource Identifier (URI) を使用することによって行います。クライアントは、必要に応じてリソースを変更または削除するのに十分な情報をリソース表現に持っています。サーバーは、リソースをさらに説明するメタデータを送信することにより、この条件を満たします。クライアントは、表現をさらに処理する方法に関する情報を受け取ります。サーバーは、クライアントがリソースを最適に使用する方法に関するメタデータを含む自己記述型メッセージを送信することにより、これを実現します。クライアントは、タスクを完了するために必要な他のすべての関連リソースに関する情報を受け取ります。サーバーは、クライアントがより多くのリソースを動的に検出できるように、表現でハイパーリンクを送信することによってこれを実現します。ステートレス REST アーキテクチャでは、ステートレスとは、サーバーが以前のすべてのリクエストとは無関係にすべてのクライアントリクエストを完了する通信方法を指します。クライアントは任意の順序でリソースをリクエストでき、すべてのリクエストはステートレスであるか、他のリクエストから分離されています。この REST API 設計の制約は、サーバーが毎回リクエストを完全に理解して実行できることを意味します。階層型システム階層型システムアーキテクチャでは、クライアントはクライアントとサーバーの間の他の許可された仲介者に接続でき、サーバーからのレスポンスを引き続き受信します。サーバーは、他のサーバーにリクエストを渡すこともできます。RESTful ウェブサービスは、セキュリティ、アプリケーション、ビジネスロジックなどの複数のレイヤーを備えた複数のサーバーで実行し、連携してクライアントリクエストを満たすように設計することができます。これらのレイヤーは、クライアントからは見えないままです。キャッシュ可能性 RESTful ウェブサービスは、サーバーの応答時間を改善するためにクライアントまたは仲介者にいくつかのレスポンスを保存するプロセスであるキャッシングをサポートします。例えば、すべてのページに共通のヘッダーとフッターの画像があるウェブサイトにアクセスするとします。新しいウェブサイトのページにアクセスするたびに、サーバーは同じ画像を再送信する必要があります。これを回避するために、クライアントは最初のレスポンス後にこれらの画像をキャッシュまたは保存し、キャッシュから直接画像を使用します。RESTful ウェブサービスは、自らをキャッシュ可能またはキャッシュ不可として定義する API レスポンスを使用してキャッシュを制御します。オンデマンドのコード REST アーキテクチャスタイルでは、サーバーはソフトウェアプログラミングコードをクライアントに転送することにより、クライアント機能を一時的に拡張またはカスタマイズできます。例えば、任意のウェブサイトで登録フォームに入力すると、ブラウザは、電話番号の誤りなど、間違いをすぐに強調表示します。サーバーから送信されたコードにより、これを行うことができます。

RESTful API とは?

AWS アカウントを今すぐ無料で作成

無料の機械学習オファーを詳しく見る

機械学習アプリケーションをクラウドで無料で構築、デプロイ、実行

機械学習サービスをご覧ください

極めて包括的な一連の ML サービスでイノベーションを加速

機械学習トレーニングをご覧ください

AWS のエキスパートが構築したコンテンツで機械学習のトレーニングを始めましょう

機械学習のブログをご覧ください

RESTful API とは

RESTful API は、2 つのコンピュータシステムがインターネットを介して安全に情報を交換するために使用するインターフェイスです。ほとんどのビジネスアプリケーションは、さまざまなタスクを実行するために、他の内部およびサードパーティーのアプリケーションと通信する必要があります。例えば、毎月の給与明細を生成するには、内部アカウントシステムが顧客の銀行システムとデータを共有して、請求を自動化し、内部タイムシートアプリケーションと通信する必要があります。RESTful API は、安全で信頼性が高く、効率的なソフトウェア通信標準に準拠しているため、この情報交換をサポートしています。

API とは

アプリケーションプログラミングインターフェイス (API) は、他のソフトウェアシステムと通信するために従う必要のあるルールを定義します。デベロッパーは API を公開または作成して、他のアプリケーションがプログラムで自身のアプリケーションと通信できるようにします。例えば、タイムシートアプリケーションは、従業員の氏名と日付の範囲をリクエストする API を公開します。この情報を受け取ると、従業員のタイムシートを内部で処理し、その日付範囲で働いた時間数を返します。

ウェブ API は、クライアントとウェブ上のリソース間のゲートウェイと考えることができます。

クライアント

クライアントは、ウェブからの情報にアクセスしたいユーザーです。クライアントは、API を使用する個人またはソフトウェアシステムの場合があります。例えば、デベロッパーは気象システムから気象データにアクセスするプログラムを作成できます。または、同じデータへは、天気予報のウェブサイトに直接アクセスしたときにブラウザからアクセスできます。

リソース

リソースは、さまざまなアプリケーションがクライアントに提供する情報です。リソースは、画像、動画、テキスト、数字、または任意のタイプのデータである可能性があります。クライアントにリソースを提供するマシンは、サーバーとも呼ばれます。組織は API を使用して、セキュリティ、制御、および認証を維持しながら、リソースを共有し、ウェブサービスを提供します。さらに、API は、どのクライアントが特定の内部リソースにアクセスできるかを判断するのに役立ちます。

REST とは

Representational State Transfer (REST) は、API の動作に条件を課すソフトウェアアーキテクチャです。REST は当初、インターネットなどの複雑なネットワークでの通信を管理するためのガイドラインとして作成されました。REST ベースのアーキテクチャを使用して、大規模で高性能で信頼性の高い通信をサポートできます。簡単に実装および変更できるため、あらゆる API システムに可視性とクロスプラットフォームのポータビリティをもたらします。

API デベロッパーは、いくつかの異なるアーキテクチャを使用して API を設計できます。REST アーキテクチャスタイルに従う API は、REST API と呼ばれます。REST アーキテクチャを実装するウェブサービスは、RESTful ウェブサービスと呼ばれます。RESTful API という用語は、通常、RESTful web API を指します。ただし、REST API と RESTful API という用語は同じ意味で使用できます。

以下は、REST アーキテクチャスタイルの原則の一部です。

統一されたインターフェイス

統一されたインターフェイスは、RESTful ウェブサービスの設計の基本であり、サーバーが標準形式で情報を転送することを示します。フォーマットされたリソースは、REST では「表現」と呼ばれます。この形式は、サーバーアプリケーション上のリソースの内部表現とは異なる場合があります。例えば、サーバーはデータをテキストとして保存できますが、HTML 表現形式で送信します。

統一されたインターフェイスは、次の 4 つのアーキテクチャ上の制約を課します。

リクエストはリソースを特定する必要があります。これは、Uniform Resource Identifier (URI) を使用することによって行います。
クライアントは、必要に応じてリソースを変更または削除するのに十分な情報をリソース表現に持っています。サーバーは、リソースをさらに説明するメタデータを送信することにより、この条件を満たします。
クライアントは、表現をさらに処理する方法に関する情報を受け取ります。サーバーは、クライアントがリソースを最適に使用する方法に関するメタデータを含む自己記述型メッセージを送信することにより、これを実現します。
クライアントは、タスクを完了するために必要な他のすべての関連リソースに関する情報を受け取ります。サーバーは、クライアントがより多くのリソースを動的に検出できるように、表現でハイパーリンクを送信することによってこれを実現します。

ステートレス

REST アーキテクチャでは、ステートレスとは、サーバーが以前のすべてのリクエストとは無関係にすべてのクライアントリクエストを完了する通信方法を指します。クライアントは任意の順序でリソースをリクエストでき、すべてのリクエストはステートレスであるか、他のリクエストから分離されています。この REST API 設計の制約は、サーバーが毎回リクエストを完全に理解して実行できることを意味します。

階層型システム

階層型システムアーキテクチャでは、クライアントはクライアントとサーバーの間の他の許可された仲介者に接続でき、サーバーからのレスポンスを引き続き受信します。サーバーは、他のサーバーにリクエストを渡すこともできます。RESTful ウェブサービスは、セキュリティ、アプリケーション、ビジネスロジックなどの複数のレイヤーを備えた複数のサーバーで実行し、連携してクライアントリクエストを満たすように設計することができます。これらのレイヤーは、クライアントからは見えないままです。

キャッシュ可能性

RESTful ウェブサービスは、サーバーの応答時間を改善するためにクライアントまたは仲介者にいくつかのレスポンスを保存するプロセスであるキャッシングをサポートします。例えば、すべてのページに共通のヘッダーとフッターの画像があるウェブサイトにアクセスするとします。新しいウェブサイトのページにアクセスするたびに、サーバーは同じ画像を再送信する必要があります。これを回避するために、クライアントは最初のレスポンス後にこれらの画像をキャッシュまたは保存し、キャッシュから直接画像を使用します。RESTful ウェブサービスは、自らをキャッシュ可能またはキャッシュ不可として定義する API レスポンスを使用してキャッシュを制御します。

オンデマンドのコード

REST アーキテクチャスタイルでは、サーバーはソフトウェアプログラミングコードをクライアントに転送することにより、クライアント機能を一時的に拡張またはカスタマイズできます。例えば、任意のウェブサイトで登録フォームに入力すると、ブラウザは、電話番号の誤りなど、間違いをすぐに強調表示します。サーバーから送信されたコードにより、これを行うことができます。

RESTful API の利点

RESTful API には、次の利点があります。

スケーラビリティ

REST API を実装するシステムは、REST がクライアントとサーバーの相互作用を最適化するため、効率的に拡張できます。サーバーは過去のクライアントリクエスト情報を保持する必要がないため、ステートレスはサーバーの負荷を取り除きます。適切に管理されたキャッシングにより、クライアントとサーバー間の相互作用が部分的または完全になくなります。これらすべての機能がスケーラビリティに役立ち、パフォーマンスを低下させる通信のボトルネックを引き起こすことはありません。

柔軟性

RESTful ウェブサービスは、クライアントとサーバーの完全な分離をサポートします。これらは、さまざまなサーバーコンポーネントを簡素化および分離して、各部分が独立して進化できるようにします。サーバーアプリケーションでのプラットフォームまたはテクノロジの変更は、クライアントアプリケーションには影響しません。アプリケーション機能を階層化する機能により、柔軟性がさらに向上します。例えば、デベロッパーは、アプリケーションロジックを書き直すことなく、データベースレイヤーに変更を加えることができます。

独立

REST API は、使用されるテクノロジーに依存しません。API 設計に影響を与えることなく、さまざまなプログラミング言語でクライアントアプリケーションとサーバーアプリケーションの両方を作成できます。また、通信に影響を与えることなく、どちらの側でも基盤となるテクノロジーを変更できます。

RESTful API の仕組み

RESTful API の基本的な機能は、インターネットの閲覧と同じです。クライアントは、リソースが必要なときに API を使用してサーバーに接続します。API デベロッパーは、サーバーアプリケーションの API ドキュメントで、クライアントが REST API をどのように使用するかを説明します。以下は REST API コールの一般的な手順です。

クライアントはサーバーにリクエストを送信します。クライアントは API ドキュメントに従って、サーバーが理解できる方法でリクエストをフォーマットします。
サーバーはクライアントを認証し、クライアントがそのリクエストを行う権利を持っていることを確認します。
サーバーはリクエストを受信し、内部で処理します。
サーバーはクライアントにレスポンスを返します。レスポンスには、リクエストが成功したかどうかをクライアントに伝える情報が含まれています。レスポンスには、クライアントがリクエストした情報も含まれます。

REST API のリクエストとレスポンスの詳細は、API デベロッパーが API を設計する方法によってわずかに異なります。

RESTful API クライアントリクエストの内容

RESTful API には、次の主要コンポーネントを含むリクエストが必要です。

一意のリソース識別子

サーバーは、一意のリソース識別子を使用して各リソースを識別します。REST サービスの場合、サーバーは通常、Uniform Resource Locator (URL) を使用してリソースの識別を行います。URL は、リソースへのパスを指定します。URL は、任意のウェブページにアクセスするためにブラウザに入力するウェブサイトアドレスに似ています。URL はリクエストエンドポイントとも呼ばれ、クライアントが何を必要としているかをサーバーに明確に指定します。

方法

デベロッパーは、ハイパーテキスト転送プロトコル (HTTP) を使用して RESTful API を実装することがよくあります。HTTP メソッドは、リソースに対して何をする必要があるかをサーバーに通知します。以下、4 つの一般的な HTTP メソッドを説明します。

GET

クライアントは GET を使用して、サーバー上の指定された URL にあるリソースにアクセスします。GET リクエストをキャッシュし、RESTful API リクエストでパラメータを送信して、送信前にデータをフィルター処理するようサーバーに指示できます。

POST

クライアントは POST を使用してサーバーにデータを送信します。データには、リクエストのデータ表現が含まれています。同じ POST リクエストを複数回送信すると、同じリソースを複数回作成するという副作用があります。

PUT

クライアントは PUT を使用して、サーバー上の既存のリソースを更新します。POST とは異なり、RESTful ウェブサービスで同じ PUT リクエストを複数回送信しても同じ結果が得られます。

DELETE

クライアントは、DELETE リクエストを使用してリソースを削除します。DELETE リクエストは、サーバーの状態を変更できます。ただし、ユーザーが適切な認証を持っていない場合、リクエストは失敗します。

HTTP ヘッダー

リクエストヘッダーは、クライアントとサーバー間で交換されるメタデータです。例えば、リクエストヘッダーは、リクエストとレスポンスの形式を示し、リクエストのステータスに関する情報などを提供します。

データ

REST API リクエストには、POST、PUT、およびその他の HTTP メソッドが正常に機能するためのデータが含まれている場合があります。

パラメータ

RESTful API リクエストには、サーバーに実行する必要のある詳細を提供するパラメータを含めることができます。以下は、いくつかの異なるタイプのパラメータです。

URL の詳細を指定するパスパラメータ。
リソースに関する詳細情報をリクエストするクエリパラメータ。
クライアントを迅速に認証する Cookie パラメータ。

RESTful API 認証方法とは

RESTful ウェブサービスは、レスポンスを送信する前にリクエストを認証する必要があります。認証は、アイデンティティを検証するプロセスです。例えば、ID カードや運転免許証を提示することでアイデンティティを証明できます。同様に、RESTful サービスクライアントは、信頼を確立するためにサーバーに対してアイデンティティを証明する必要があります。

RESTful API には、次の 4 つの一般的な認証方法があります。

HTTP 認証

HTTP は、REST API を実装するときに直接使用できるいくつかの認証スキームを定義します。以下は、これらのスキームの 2 つです。

Basic 認証

Basic 認証では、クライアントはリクエストヘッダーでユーザー名とパスワードを送信します。それらを base64 でエンコードします。これは、安全な送信のためにペアを 64 文字のセットに変換するエンコード手法です。

Bearer 認証

Bearer 認証という用語は、トークンベアラーにアクセスコントロールを与えるプロセスを指します。ベアラートークンは通常、ログインリクエストに対応してサーバーが生成する暗号化された文字列です。クライアントは、リソースにアクセスするためにリクエストヘッダーでトークンを送信します。

API キー

API キーは、REST API 認証のもう 1 つのオプションです。このアプローチでは、サーバーは一意に生成された値を初めてのクライアントに割り当てます。クライアントがリソースにアクセスしようとするたびに、一意の API キーを使用して自身を検証します。クライアントはキーを送信する必要があるため、API キーの安全性は低くなり、ネットワークの盗難に対して脆弱になります。

OAuth

OAuth は、パスワードとトークンを組み合わせて、あらゆるシステムへの安全性の高いログインアクセスを実現します。サーバーは最初にパスワードをリクエストし、次に認証プロセスを完了するために追加のトークンをリクエストします。トークンはいつでも、また特定のスコープと寿命で経時的にチェックできます。

RESTful API サーバーのレスポンスの内容

REST の原則では、サーバーのレスポンスに次の主要コンポーネントが含まれている必要があります。

ステータスライン

ステータスラインには、リクエストの成功または失敗を伝える 3 桁のステータスコードが含まれています。例えば、2XX コードは成功を示しますが、4XX および 5XX コードはエラーを示します。3XX コードは URL リダイレクトを示します。

一般的なステータスコードは次のとおりです。

200: 一般的な成功レスポンス
201: POST メソッドの成功レスポンス
400: サーバーが処理できない不正確なリクエスト
404: リソースが見つかりません

メッセージ本文

レスポンス本文には、リソース表現が含まれています。サーバーは、リクエストヘッダーに含まれる内容に基づいて、適切な表現形式を選択します。クライアントは、データがプレーンテキストでどのように書き込まれるかを定義する XML または JSON 形式の情報をリクエストできます。例えば、クライアントが John という名前の人の名前と年齢をリクエストした場合、サーバーは次のように JSON 表現を返します。

'{"name":"John", "age":30}'

ヘッダー

レスポンスには、レスポンスに関するヘッダーまたはメタデータも含まれます。これらは、レスポンスに関するより多くのコンテキストを提供し、サーバー、エンコーディング、日付、コンテンツタイプなどの情報が含まれます。

AWS による RESTful API 管理の支援方法

フルマネージドサービスの Amazon API Gateway を利用すれば、デベロッパーは規模にかかわらず簡単に API の作成、公開、保守、モニタリング、保護が行えます。API Gateway を使用すれば、リアルタイム双方向通信アプリケーション用の RESTful API を作成できます。

API Gateway を使用すると、次のことができます。

ユーザーのために API リクエストとレスポンスの両方で高速パフォーマンスを実現します。
AWS Identity and Access Management (IAM) と Amazon Cognito を使用して API へのアクセスを許可でき、どちらもネイティブ OAuth サポートを提供します。
API Gateway と同時に同じ API の複数のバージョンを実行して、新しいバージョンをすばやく反復、テスト、リリースします。
API Gateway からのパフォーマンスメトリクスと API コール、データレイテンシー、およびエラー率に関する情報をモニタリングします。

ステップバイステップガイダンスと AWS アカウントの作成をご覧になり、API Gateway の利用を今すぐ開始しましょう。

AWS の次のステップ

追加の製品関連リソースを確認する

アプリケーション統合サービスの詳細

無料のアカウントにサインアップ

AWS 無料利用枠にすぐにアクセスできます。

API Gateway 無料利用枠にサインアップする

コンソールで構築を開始する

AWS マネジメントコンソールで構築を始めましょう。

サインイン