REST API

REST API

API「Application Programming Interface」を提供する方法の一つREST API(RESTful APIともいう)の特徴と設計思想について紹介します。

APIとは何か

API「Application Programming Interface」とはアプリケーションの機能の一部を外部に向けて公開する仕組み(Interface)のことを指します。自社で開発したアプリケーションの機能を第三者に公開することで、そのアプリケーションが世の中で広く使われることを目的として公開します。

具体的には、FacebookはAPIを無料で公開することにより世の中の様々なソフトウェアに認証機能を提供しています。Twitterのチャット機能が埋め込まれているWEBサイトや、Google Mapが埋め込まれているWEBサイトを良く利用するかと思いますが、それらの機能は全てTwitterやGoogle MapのAPIを利用して開発されています。

APIの種類は大きくSOAP APIとREST APIに大別されます。SOAP(SimpleObject Access Protocol) APIは、XMLフォーマットで規定された規格で以前広く利用されていたましたが、現在主流で利用されているのはREST APIなので、こちらについて詳しく解説します。

REST APIとは

REST APIとは、APIの中でもRESTと呼ばれる設計原則に従って策定されたものです。RESTは「Representational State Tranfer」の頭文字を取ったもので、リソース指向型アーキテクチャとも呼ばれるROA(Resource Oriented Architecture)を引き継いだシステム設計の方法論・思想です。このRESTの設計思想に従ったAPIは具体的は以下のような特徴を持ちます。

REST APIの特徴(設計原則)

URIによる機能提供(Addressability)

先ほど、APIを用いて認証機能やチャット機能を提供する具体例を紹介しましたが、このようにAPIは利用者に対して機能や情報データなどの様々な「リソース」提供します。

REST APIの場合、この「リソース」へのアクセスはHTTPプロトコルを用いるため、接続先をURI「Uniform Resource Identifier」で指定します。(例:http://www.xyz.com/abc/efg などの形式)このURIはインターネット上で一意に識別され、利用者はインターネット上のリソースに対してアクセスすることが可能となります。

REST APIのURIは文字から機能や内容の予測をしやすいものとする方が好ましく、例えばexample/user/editとあればユーザー情報を編集する内容かなといったように利用者が理解しやすくなります。

同じリソースに対するすべてのAPIリクエストは、リクエストの送信元に関係なく、同じように見える必要があります。 REST APIは、ユーザーの名前や電子メールアドレスなど、同じデータが1つのURI(Uniform Resource Identifier)にのみ属するようにする必要があります。リソースは大きすぎてはいけませんが、クライアントが必要とする可能性のあるすべての情報が含まれている必要があります。

HTTPメソッドのみによるリソース操作性(Uniform Interface)

リソースへのアクセス(リクエスト)は、GET、PUT、POST、DELETEなどのHTTPメソッドを使って行います。厳格なルールではないのですが、リソースの取得(Read)にはGETメソッド、リソースの作成(Create)にはPOSTメソッドを利用するなど、統一されたルールを利用することで、設計者・機能の利用者に理解しやすく、互換性の高い仕組みにすることが一般的です。

リクエストを受けてレスポンスを返す際、処理結果はHTTPステータスコードで返され、レスポンスの中身はXMLやHTML、JSONなどの形式で返されることが一般的です。レスポンスの内容を、適切なHTTPステータスコードで返せるように設計することで、利用者に対してAPIの使用方法や状況を正しく伝えることができます。

HTTPステータスコードには、リクエストが成功し要求した内容が正常に返ってきていることを示す「200 OK」やリクエスト先のリソースが存在しないことを示す「404 Not Found」、サーバー側で問題が発生しており正常にレスポンスを返さない状態である「500 Internal Server Error」などがあり、これらが多く活用されます。

クライアントとサーバーの独立性(Client-server decoupling)

REST APIの設計では、クライアントアプリケーションとサーバーアプリケーションは、互いに完全に独立していなければなりません。クライアントアプリケーションが知るべき情報は、要求されたリソースのURIだけであり、それ以外の方法でサーバーアプリケーションとやり取りすることはできないようにすべきです。同様に、サーバーアプリケーションは、HTTP経由で要求されたデータを渡す以外に、クライアントアプリケーションを変更するべきではありません。

ステートレス(Statelessness

REST APIはステートレスであり、各リクエストにはその処理に必要なすべての情報が含まれている必要があります。言い換えれば、REST APIはサーバー側のセッションを一切必要としません。サーバーアプリケーションは、クライアントのリクエストに関連するデータを保存しないように設計すべきです。

ステートレスとは状態が無いという意味であり、リクエストを受けるAPI(サーバー側)が利用者の状態を管理しないことを指します。反対にCookieを利用したり、ユーザー情報をDBに保存したりすることで利用者毎にサービスを提供するアプリはステートフルと言います。例えば、誰がアクセスしても同じ画面を提供するニュースサイトなどはステートレス、ユーザーによって表示内容が変化するマイページなどはステートフルです。

REST APIはステートレスとすることを基本とし、利用者がリソースに対してアクセスした場合、常に同じレスポンスが返ります。アクセス数が増加した際などは、API側のサーバーをスケールアウトさせることでリクエストを容易に負荷分散可能なことからステートレスは大規模なアプリケーション等の利用に最適です。

キャッシュ性(Cacheability)※オプション

可能であれば、リソースはクライアント側またはサーバー側でキャッシュ可能であるべきです。また、サーバーのレスポンスには、配信されたリソースに対してキャッシュが許可されているかどうかの情報を含める必要があります。キャッシュを行うことで、クライアント側でパフォーマンスを向上させ、サーバー側でスケーラビリティを向上させます。

階層化された設計(Layered system architecture)※オプション

REST APIでは、呼び出しと応答は異なるレイヤーを経由します。経験則として、クライアントアプリケーションとサーバーアプリケーションが互いに直接接続すると仮定しないでください。一連の通信の際には、いくつもの異なる仲介者が存在する可能性があります。REST APIは、クライアントもサーバーも、それがエンドアプリケーションと通信しているのか、仲介者と通信しているのかが分からないように設計する必要があります。

REST APIを利用したマイクロサービス化

REST APIはステートレスであることから、巨大なシステムをマイクロサービス化する際はREST APIを用いた設計が必須になります。

リッチなWEBアプリケーションを構築する際は当然ユーザー管理などの機能を提供する際にステートフルな仕組みを実装する必要がありますが、ユーザー管理などはフロントエンドのAPIのみに限定した設計にする工夫が必要になります。

参考

https://www.ibm.com/cloud/learn/rest-apis

アプリケーションカテゴリの最新記事