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