Webアプリ開発において、フロントエンド開発者に必要なスキルは多岐にわたります。
例えば、テスト・デバッグ、バージョン管理、UI・UX、コミュニケーション能力、SEO、クライアントの理解、クロスプラットフォーム、クラウドインフラ、セキュリティ、アジャイル開発手法などが挙げられます。
これらの中でも、REST APIの理解は必須スキルの一つとなっています。
REST APIの学習は、主にバックエンド開発者が行いますが、現代ではフロントエンド開発者もREST APIの基本的な理解が必要となる場合があります。
REST APIは、最も人気のあるAPIの一つであり、初心者にも理解しやすいものです。
REST APIを理解するためには、まずAPIとは何かを理解する必要があります。
APIとは、エンジニアがプログラムを作成する際に使用するインターフェースのことであり、主要なOSには1000を超えるAPI呼び出しがあります。
ただし、APIには各OSに同じ操作を呼び出すための対応されたものがありますが、実際の構文やコーディングはプラットフォーム間で大幅に異なる場合があります。そのため、統合開発環境、機能、インターフェースなどを参照する必要があります。
API
APIとは、「Application Programming Interface」アプリケーションプログラミングインターフェイスの略称であり、数十年前から存在している標準的な方法論です。
APIは、サーバーベースのアプリケーションベンダーやOSがクライアントがサーバーリソースにアクセスできるようにするために必要とされ、Webが普及するにつれてWeb開発に移行しました。
APIを使用することで、企業はアプリケーションのデータや機能を外部のサードパーティ開発者、ビジネスパートナー、および企業内の内部部門などに公開することができます。これにより、サービスや製品が相互に通信し、文書化されたインターフェイスを介して相互のデータや機能を活用できるようになります。
APIを使用する際には、あなたは、実装方法を知る必要はありません。
APIを使用して他の製品やサービスと通信するだけです。
たとえば、ウェブサイトに地図を組み込んだり、最新のツイートのリストを表示したりする場合、GoogleマップやTwitterに直接アクセスすることはできません。
そのため、承認されたユーザーがサイトからデータを取得できるようにするAPIを提供します。Google Maps APIやTwitter APIは非常に人気があり、最も広く使われています。
APIには、OSやアプリケーションソフト、またはWebアプリケーションの機能の一部を外部から利用できるようにするための規約があります。
APIの一部である各呼び出しには定義された構文があり、APIを提供する各ベンダーは、通常は自社のサイトで、場合によっては「GitHub」や「ProgrammableWeb」などのサイトでその構文を文書化します。
ほとんどのAPIには、開発者がデータを作成し取得、更新、および削除できるようにするいくつかのメソッドまたは操作があります。
これらのメソッドを実装するために使用されるのは、それぞれPOST、GET、PUT、およびDELETEです。
各メソッドは通常、操作対象のデータを含む定義済みの形式(JSONまたはXML)のファイル形式でペイロードを受け取り、APIが相互作用できるアドレスとして機能するURLを介してアプリケーションからWebサーバーに処理されます。
有効なリクエストを受信した後、APIは外部のプログラムまたはWebサーバーを呼び出し、要求された情報を含む応答をAPIに送信します。APIはそれらデータを最初のリクエスト元であるアプリケーションに転送します。
APIは、UIとは異なり、コンピューターやアプリケーションが使用するように設計されています。
APIの種類は様々で、それらを分類する方法も多数あります。
ほとんどのAPIは、インターネットを介してアプリケーションのデータや機能を公開するWeb APIです。
最も一般的なものは、オープンAPI、パートナーAPI、内部API、および複合APIです。
・ オープンAPI：は、開発者が公開して開発するAPIであり、インターネット上で実行され、自由に共有できるため、ネットワークアクセス可能なサービスの所有者はユーザーにユニバーサルアクセスを提供できます。
・ Partner API：はプライベートであり、組織外の特定の統合パートナーとのみ共有されます。
・ 内部API：はプライベートであり、チーム、部門、会社、または組織によってのみ使用されます。
・ 複合API：は、APIリクエストを1つのAPI呼び出しに連続してバンドルするための設計アプローチであり、複数のリクエストを組み合わせて1つのAPI呼び出しを行うことで機能します。
API プロトコル
随時増加するWeb APIの利用に伴い、特定のプロトコルが開発され、ユーザーにデータ型とコマンドの指定ルールを提供するようになりました。
その中でも、以下の4つのプロトコルが代表的です。
・ SOAP（Simple Object Access Protocol）
XMLで構築されたAPIプロトコルで、SMTPおよびHTTPを介してデータを送受信できます。
・ XML-RPC
特定の形式のXMLに依存してデータを転送するプロトコルです。
RPCは「Remote Procedure Call」（リモートプロシージャコール）の略称です。
RPC（リモートプロシージャコール）とは、ネットワーク上で別のコンピューター上にあるプログラムの関数を呼び出すための技術です。
つまり、自分のコンピューター上にあるプログラムから、別のコンピューター上にあるプログラムの関数を呼び出すことができます。
これにより、ネットワーク上で分散処理を行うことができ、複数のコンピューターを利用して処理を高速化することができます。 例えば、あるWebサイトでユーザーがログインすると、その情報を別のサーバーに送信して認証を行う必要があります。この場合、RPCを使用して、ログイン情報を別のサーバーに送信し、認証処理を行うことができます。
RPCは、SOAPやXML-RPC、JSON-RPCなどのプロトコルで実現されることが多く、Webサービスや分散システムなどで広く利用されています。 ・ JSON-RPC
XML-RPCに非常によく似たプロトコルで、XML形式ではなくJSONを使用してデータを転送します。
・ REST
REST APIまたはRESTful APIとも呼ばれ、HTTP（多くの場合はWebサービス）で動作するアプリケーションを構築するための制約があるソフトウェアアーキテクチャスタイルです。
本日は、初心者向けにこの、RESTについて解説します。
以上が、Web APIのプロトコルの代表的なものについての説明です。
RESTとは？
RESTは、「Representational State Transfer」の略称であり、日本語では「表現状態転移」と訳されます。通常は「REST」と略されます。
このアーキテクチャは、2000年にアメリカのコンピュータ科学者Roy Fielding氏によって提唱され、彼の論文「World Wide Web」に記載されています。
RESTは、Webサービスへのアクセスを提供するサーバーと、要求と応答を転送する中間コンポーネントの役割を提供します。
RESTを使用すると、サーバーはアプリケーションのパフォーマンスを向上させるために、応答をキャッシュすることができます。 RESTは、APIを作成する際に従うべき一連のルールとガイドラインであり、開発者がステートレスなリソースベースのWebサービスを作成することを可能にします。
現在、APIの大部分は「RESTful」になっており、開発者がより効率的かつ堅牢なWebサービスを作成するための重要なツールとなっています。
REST API
REST APIまたは(RESTful APIとも呼ばれます)は、 RESTの制約に準拠するAPIとなりインターフェースとして機能致します。
REST APIは、Web開発で最も一般的に使用されているAPIの1つです。
クライアントとサーバー間の通信は『HTTP』を介して行われます。
基本的に他のWebサイトと同じように機能します。クライアントからサーバーへの呼び出しが行われ、データはHTTPプロトコルを介して受信されます。
Web開発者に馴染みのあるHTTPコーディングに依存しているという事になります。
REST APIがニーズに適したタイプのAPIであるかどうかを検討する際に、RESTではそれぞれ重要な制約があります。
アドレス可能性(エンドポイント)
REST APIは、Web開発者にとって馴染みのあるHTTPコーディングに依存しています。
REST APIがニーズに適したタイプのAPIであるかどうかを検討する際に、RESTにはそれぞれ重要な制約があります。
まず、APIは「リクエスト」と「レスポンス」を使用して操作を実行します。APIがWebアプリケーションまたはWebサーバーから「要求」情報を送信すると、「応答」を受信します。
APIがリクエストを送信する場所、またはリソースが存在する場所が「エンドポイント」です。
REST APIでは、エンドポイントは通信チャンネルの一端であり、各エンドポイントはREST APIが機能の実行に必要なリソースにアクセスできる場所となります。
RESTの原則は、システム内のすべてのオブジェクトが、それらを見つけることができる全ての情報が一意の識別子を持つ必要があることを示しており、RESTではこれは「URI」で実現されます。
URIは「Uniform Resource Identifier」の略称であり、Webの場合はURLとなります。
RESTでは、アドレス指定可能なURIによって公開されます。例えば、以下のようなURIがあります。
https://service.com/users/{username}
このURIは、各APIリクエストでサービスから特定のユーザーのユーザー詳細を取得するための独自のエンドポイントでもあります。
HTTPクライアントが送信されることで、データリソースとやり取りすることができます。
クライアントとサーバーの分離
RESTは分散型アプローチであり、クライアントとサーバーが完全に分離されています。
このアーキテクチャでは、クライアントはエンドポイントを使用してバックエンドサービスにアクセスし、必要な権限を持つすべてのクライアントがリソースにアクセスできます。
バックエンドサービスは、クライアントの実装について心配する必要がなく、必要に応じてリソースにアクセスすることができます。
REST APIを使用することにより、異なるクライアントが同じRESTエンドポイントにアクセスし、同じアクションを実行し、同じ応答を受け取ることができます。
開発者は、個別でのコードで様々なテクノロジーを活用し、クライアントごとに多種多様な実装を行うことが容易になります。また、新しいタイプのクライアントを導入したり、既存のクライアントを変更しても、バックエンドサービスの機能には影響がありません。
RESTのアーキテクチャにより、クライアントアプリケーションの情報は、要求されたリソースのURIだけになります。
つまり、クライアントとサーバーが完全に分離されているため、要求が開始された場所に関係なく、クライアントは必要な情報を取得することができます。
統一されたインターフェース
RESTサービスの設計において、統一されたインターフェース制約は基本となります。
この制約により、アーキテクチャが簡素化され、各パーツを独立して進化させることができます。つまり、統一されたインターフェースにより、クライアントとサーバー間で単一の言語で通信することができます。
この統一されたインターフェースには、URIリソース、作成、読み取り、更新、削除などが含まれます。また、JSONでHTTPを使用するなど、クライアントとサーバー間で通信するための標準化された手段を提供する必要があります。
クライアントとサーバー間の通信は、定義された操作セットを備えたシンプルでよく知られたインターフェースに基づいています。
利用可能なHTTPメソッドは12種類ありますが、ほとんどのサービスでは主にCRUD操作にマップされる4つを使用します。
これらは、HTTP PUT、HTTP POST、HTTP DELETE、HTTP GETです。
開発者は、これらのREST APIコマンドを使用して、アプリケーションまたはサービス内のさまざまな「リソース」に対してアクションを実行します。
RESTとHTTPは、明確に異なるものです。
RESTは通信プロトコルではありませんが、HTTPは「インターネット技術特別調査委員会」によって維持されている通信プロトコルです。
HTTPは、RESTfulシステムの多くの機能を備えており、明確に定義されたプロトコルです。ただし、RESTfulシステムではHTTPの使用は必須ではありません。
RESTは、Webアーキテクチャのスタイルの一つです。RESTは、クライアントとサーバー間でリソースの表現とやり取りするためのアーキテクチャスタイルであり、HTTPを含む様々なプロトコルで実装することができます。
一方、HTTPは、「Hypertext Transfer Protocol」の略で、Web上でデータをやり取りするためのプロトコルです。
HTTPは、WebブラウザとWebサーバー間でHTMLページや画像などのデータをやり取りするために使用されます。
つまり、RESTはアーキテクチャスタイルであり、HTTPはプロトコルです。
RESTは、クライアントとサーバー間でリソースの表現とやり取りするためのアーキテクチャスタイルであり、HTTPはその実装の一つに過ぎないという事です。
RESTとHTTPという用語を同じ意味で使用することがありますが、真実はそれらが異なるものであるということになります。
ただし、HTTPはRESTfulシステムにおいて最も一般的に使用されるプロトコルであり、RESTfulシステムを設計する際には、HTTPを使用することが推奨されます。
以上のように、RESTサービスの設計においては、統一されたインターフェース制約が重要であり、HTTPを使用することが一般的ですが、RESTとHTTPは異なるものであることを理解することが重要です。
ステートレス
RESTはステートレスに設計されています。
これは、HTTPリクエストが独立している必要があることを意味します。
クライアントとサーバーが通信する際に必要な情報は、常に要求に含まれます。
つまり、クライアント側に保持されるセッション状態は存在しません。
ステートレスとは、アプリケーションが存在するサーバーにクライアントセッション(状態)データを保存しないことを意味します。セッション状態は、サーバーによってデータベースなどの別のサービスに転送され、一定期間にわたって永続的な状態を維持して認証を許可します。クライアントが次に新しい状態遷移の開始を選択したときに使用できるリンクが含まれます。
サーバーはクライアントの状態について何も知る必要はありません。
同様に、クライアントもサーバーの状態について何も知る必要はありません。データの維持がされないため、一度に全ての情報を送信します。
サーバーとクライアントの両方が、前のメッセージを見なくとも受信したメッセージを理解できます。
アプリケーションの状態の管理は、完全にクライアントの責任となります。各要求は自己完結型となり、ローカルに保存されるため、保持するデータにのみ依存します。ステートレスの制約は、コマンドではなくリソースを使用することで適用されます。
つまり、リソースはURIで与えられるため、自然にステートレスとなります。
リソースはWebの名詞であり、保存したり他のサービスに送信したりする必要のあるオブジェクト、ドキュメントなどを表します。
以上がRESTのステートレス性についての説明です。
接続性
REST APIでは、API全体にハイパーリンクを組み込み、他の関連リソースを1つのレスポンスにまとめて埋め込むことが基本です。
各応答にはハイパーリンクが提供され、APIには「ハイパーリンク」と「ハイパーメディア」の利用が可能です。クライアントはハイパーリンクを使用して、現在利用できるアクションやその他のすべての情報を見つけることができます。
APIの設計には、リソース同士が適切に接続されるようにすることが重要です。
これにより、リンクを辿るだけで別のリソースにアクセスでき、使いやすいAPIを提供することができます。
ここで、「ハイパーメディア」という用語がでましたが、ハイパーメディアとは、RESTの作成者である「Roy Fielding」氏がWebがパフォーマンス・信頼性が高くかつスケーラブルなシステムで構成されていることを目的として開発した概念です。
スケーラブルなシステムとは、他のシステム(API)が提供する機能を再利用していく一方で、更新されてもなんら影響を受けないシステムのことを指します。
HATEOASとは、RESTful APIの設計原則の一つで、（「Hypermedia As The Engine Of Application State」（アプリケーション状態のエンジンとしてのハイパーメディア）の略称であり、これは、APIの利用者がAPIを使用する際に必要な情報を、API自体が提供することを意味します。
具体的には、APIのレスポンスには、そのリソースに関連する他のリソースへのリンクが含まれています。これにより、APIの利用者は、リンクをたどることで、必要な情報を取得することができます。つまり、APIの利用者は、API自体が提供する情報を活用することで、必要な情報を取得することができるのです。
HATEOASを採用することで、APIの利用者は、APIの仕様を完全に理解する必要がなくなります。また、APIの変更に対しても、APIの利用者が影響を受けることがなくなります。これは、APIの利用者がAPI自体が提供する情報を活用することで、必要な情報を取得することができるためです。
簡単に言えば、HATEOASは、APIの利用者がAPI自体が提供する情報を活用することで、必要な情報を取得することができるようにする設計原則です。
これは元々HTMLページの標準でしたが、APIの場合では異なります。
APIの大部分は、HTTP経由でアクセスできますが、RESTに完全に準拠しているわけではありません。
HATEOASに準拠するAPI作成者は、それらを「HATEOAS API」または「ハイパーメディアAPI」と呼びます。
HATEOASの「H」は「Hypermedia」を指しています。
ハイパーメディアは、このHATEOASに基づいたAPIの設計において、ハイパーリンクを含むレスポンスを指します。
しかし、HATEOASはあまり活用されることはありません。
それは、HATEOASを実装するには、APIの設計に多くの工数が必要であり、実装が複雑になることがあります。また、HATEOASを活用するためには、APIの利用者がHATEOASについて理解している必要があります。
これらの理由から、HATEOASを活用するAPIはあまり多くありません。
以上のように、REST APIではハイパーリンクを活用し、API全体を統合的に設計することが重要です。
また、HATEOASは、APIの利用者にとって使いやすいAPIを提供するための重要な概念です。
最後に
REST APIはこれらのREST設計原則である制約を厳守された「RESTful」サービスとなります。
REST APIはモバイルアプリ、ソーシャルネットワークサイト、およびその他のアプリケーションで人気が高まっています。
多くの企業がREST APIを使用し収益を生み出し、サービスを拡大し続けています。
ビジネスアプリを可能にするための最もコストを節約する方法の1つでもあります。
この記事でREST APIを理解し、アプリケーションを作成するときにそれらを流暢に使用できるようになることを願っています。
本日は以上となります。
最後まで読んで頂きありがとうございました。