APIまたはアプリケーションプログラミングインターフェイスは、異なるアプリケーション間の相互作用と通信を可能にする機能とルールを提供します。これらのインターフェースはアプリケーション統合を容易にし、開発者が強力なデジタル製品を作成できるようにします。
APIは、リクエストとレスポンスを介してアプリケーション間を仲介します。たとえば、ユーザーの既存のTwitterアカウントを介したアプリケーションへの登録は、開発者がアプリに統合したTwitterAPIを介して行われます。 APIは、要求と応答を送信するためにさまざまなプロトコルとアーキテクチャを使用します。
- XML-RPC —ネットワーク間で機能を交換できます。 XML-RPCは、XMLを使用して、クライアントからサーバーに情報を転送するための応答/要求とHTTPプロトコルを記述します。
- JSON-RPCは、XMLに似た軽量のRPCです。ここで、プロトコルはJSONでエンコードされています。非同期応答でサーバーへの呼び出しを受信できます。
- SOAP —コンピュータネットワークにWebサービスを実装するときに構造化された情報を交換するための単純なオブジェクトアクセスプロトコル。 SOAPは、オペレーティングシステムでの認証、承認、およびプロセス通信にXMLを使用します。これにより、クライアントはプラットフォームや言語に関係なく、Webサービスを呼び出して応答を受け取ることができます。
- REST API(Representative State Transfer)—クライアントサーバー実装を個別に使用するアーキテクチャスタイル。 RESTは通信にHTTPプロトコルを使用します。
この投稿では、REST APIに焦点を当てて定義し、他のAPIとの違いを分析します。
RESTAPIの定義
RESTは、HTTPプロトコルを介してAPIを設計するためのアーキテクチャスタイルです。その主な利点は、その優れた柔軟性です。
開発者は、サーバーから直接Webアプリケーションまたはサイトのユーザーにデータを提供する必要がある場合は常にRESTAPIを使用します。 REST APIの主なコンポーネント:
- クライアント —通信を開始するユーザー側(デバイス上)で起動されたクライアントまたはプログラム。
- サーバ —関数とデータへのアクセスとしてAPIを使用するサーバー。
- リソース —サーバーがクライアントに送信するコンテンツ(ビデオ、テキスト、画像)。
RESTAPIの仕組み
REST APIは、HTTPリクエストを介して通信し、データの作成、読み取り、更新、削除などの機能を実行します。これらは、CRUD操作とも呼ばれます。 RESTは、要求されたリソースに関する情報を提供し、4つのメソッドを使用してリソースの処理方法を記述します。
POST —リソースの作成。
GET —リソースを取得します。
PUT —リソースを更新します。
DELETE —リソースを削除します。
リソース
リソースは、情報の抽象化であるRESTAPIの重要な概念です。ドキュメント、画像、一時的なサービスなど、どのような情報でもかまいません。
ある時点でのリソースの状態は、データ、データを説明するメタデータ、および顧客が次の状態に移行するのに役立つハイパーメディアリンクで構成されるリソース表現と呼ばれます。
情報は、JSON、HTML、XLT、Python、またはプレーンテキストなどのさまざまな形式でクライアントに配信できます。最も人気があり、使用されているのはJSONです。これは、人間で機械可読であり、言語に依存しないためです。
リソースにアクセスするには、クライアントはリクエストを行う必要があります。サーバーはそれを受信した後、リソースに関するエンコードされたデータを使用して応答を生成します。
リクエスト構造には、HTTPメソッド(前述のCRUD)、エンドポイント、ヘッダー、本文の4つの主要コンポーネントが含まれます。
HTTPメソッドは、リソースで何をすべきかを記述します。上記では、POST、GET、PUT、DELETEの4つの使用可能なメソッドについて説明しました。
エンドポイントにはURI(Uniform Resource Identifier)が含まれています。これは、リソースを見つける方法と場所を示します。 URLまたはUniformResource Locationは、完全なWebアドレスを表す最も一般的なURIタイプです。
ヘッダーには、クライアントとサーバーに関連するデータが含まれています。ヘッダーには、認証データ(APIキー、名前、サーバーがインストールされているコンピューターに属するIPアドレス、および応答形式に関する情報)が含まれます。
本文は、追加するデータなどの追加情報をサーバーに送信するために使用されます。
RESTAPIの原則
RESTは特定のテクノロジーやプラットフォームに結び付けられていません。言語に依存しません。また、APIの構築方法も正確に指定されていません。ただし、6つのアーキテクチャ上の制約があります。これらの制約に従うことで、インターフェースを有効なRESTAPIと呼ぶことができます。これらは、サーバーが要求を処理して応答する方法を説明します。
クライアントサーバー
REST APIは、クライアントサーバーアーキテクチャスタイルを実装します。クライアントはリソースの要求を送信しており、データストレージに関連付けられていません。データストレージはサーバー内に残ります。サーバーは、ユーザーインターフェイスとの通信には関与しません。クライアントとサーバーは相互に依存して進化します。この要素により、RESTはさらに柔軟でスケーラブルになります。
統一されたインターフェース
統一されたインターフェースは、RESTAPIを区別する重要な要素です。これは、アプリケーションやデバイスのタイプを意味するのではなく、サーバーと通信するための単一の方法があることを示しています。
統一されたインターフェースには4つの原則があります。
- リソースの識別。各リソースには、リソースの状態に依存しないIDが必要です。 URLは識別子として機能します。
- 表現によるリソースの操作。 (クライアントが持つ)リソース表現には、リソースを削除または変更するために必要なデータが含まれています。クライアントは、サーバー(JSONオブジェクト)が変更、削除、または追加する必要があるという表現を送信します。
- 自己記述的なメッセージ。このようなメッセージには、受信者が理解できるようにすべての情報が含まれています。別のドキュメントやメッセージに追加情報は必要ありません。各メッセージには、サーバーが要求を解析するのに十分な情報が含まれています。
- アプリケーション状態のエンジンとしてのハイパーメディア。ハイパーメディアでは、クライアントが他のリソースを見つけることができるように、応答ごとにリンクを使用する必要があります。 RESTでは、ハイパーメディアがすべての対話に使用されます。
ステートレス
これは、サーバーにクライアントに関するデータが含まれていないことを意味します。リクエストの処理に必要なすべての情報がリクエストに含まれています。クライアントはすべてのセッション情報を保存します。
キャッシュ可能
各応答には、キャッシュ可能かどうか、および応答をキャッシュできる期間を示す情報が必要です。キャッシュ可能である場合、同様のリクエストで、クライアントはサーバーにリクエストを繰り返し送信することなく同じデータを使用できます。パフォーマンスと可用性の向上に役立ちます。
階層化システム
RESTはレイヤー階層を実装します。これにより、コンポーネントの動作に特定の制限が生じます。階層化されたシステムでは、コンポーネントは最も近いレベルにあるコンポーネントとそれらが相互作用するコンポーネントのみを見ることができます。
オンデマンドのコード
これは、クライアントがコードをダウンロードして実行できるようにするオプション機能です。
REST APIの違いは何ですか?
REST APIの6つの原則は、このインターフェースと他のタイプの主な違いと見なすことができます。さらに、いくつかのパラメーターがRESTを区別します。
まず、RESTの本質が、他のタイプとの非互換性を決定します。これは、RESTfulWebサービスを提供するために従う必要のある一連の要件をアーキテクチャが表すアーキテクチャスタイルです。たとえば、SOAPとRPCは、メッセージを記述するメッセージングプロトコルです。メッセージが満たさなければならない要件(制約)のみを指定するアーキテクチャスタイルとは異なります。
構造
通常、APIはアプリ間形式に従いますが、RESTは別の構造(クライアントサーバー)に従います。クライアントとサーバーは独立して進化しており、作業の柔軟性が向上しています。
メッセージ交換フォーマット
APIは通常、特定のメッセージ形式を使用します。たとえば、SOAPはXMLを使用します。 RESTはそのような厳密な原則には従いません。ほぼすべての形式を使用してデータを交換できます。ただし、現在、JSONが最も人気があります。
JSONの人気の背後には明らかな理由があります。それは、人間が読める形式であり、データ交換形式を分析するのが簡単です。 JSONは言語に依存せず、JavaScript以外の任意の言語で使用できます。
柔軟性
RESTは柔軟なアーキテクチャスタイルであるため、開発者は広く使用しています。より多くの帯域幅を必要とする高度なセキュリティ機能を備えたより複雑なプロトコルであるSOAPと比較すると、RESTは、開発者がそれらの要件をフォーマットで使用できるようにする単純なガイドラインで構成されています。このアーキテクチャは高性能を提供し、ダウンロード速度が重要なモバイルデバイスで特に需要があります。
ご覧のとおり、RESTには他の既知のAPIに比べて特定の利点があります。そのため、TwitterやGoogleなどのすべての大手企業が自社製品に実装しています。結局のところ、これは世界中の開発者にデータを転送するための理想的で簡単な方法であり、ソフトウェア開発のための効率的でスケーラブルなインターフェイスを作成するための実証済みのメカニズムです。