REST:Tech Basics/Keyword
RESTとは、広く普及したWebのインフラをそのまま利用して、簡易な手順でアクセスを可能にした、Webサービス向けのソフトウェア設計アーキテクチャ。
「REST(REpresentational State Transfer)」(レスト)とは、広く普及したWebのインフラをそのまま利用して、簡易な手順でWebサービスへのアクセスを可能にする仕組み。もともとはHTTPプロトコルの設計者の一人でもあるRoy Fielding氏によって2000年に提唱されたものである。
ネットワーク上のサービスへのアクセス手段は、歴史的に見てもさまざまなものがある。その中でもRESTは、Webの仕組み(HTTP手順)をそのまま利用することや、テキストベースのデータをやりとりするなど通信手順が非常に簡易なため、Webアプリケーションやスマートフォンアプリ、ソーシャルゲームなどで幅広く利用されている。
ただしRESTは、厳密なAPIの仕様というわけではなく、Webを使ったクライアント/サーバ型のシステムにおける、一種の設計原則、アーキテクチャスタイル(設計思想)である。RESTの原則に基づいて設計されたシステムやAPIは、「RESTfulなシステム」「RESTful API」などと呼ばれる。
Webアプリケーションのサービス化で広く普及
例えばTwitterは、「Twitter REST API」として、Twitterのさまざまな機能を外部から利用できるように、RESTでAPIを公開している。
- Twitter REST API[英語](twitter.com)
RESTの最大の特徴は、通常のWebブラウジングで利用するHTTP(あるいはHTTPS)を利用して、Webサービスへのアクセスが可能になる点だ。通常のWebページをブラウズするのと同様の手順で、アプリケーションはWebサービスで用意されているAPIのURI(URL)を指定してこれを呼び出し、テキスト形式のデータをレスポンス(応答)として受け取って処理する。HTTPプロトコルを利用することから、ステートレス(呼び出しごとに処理が独立している)なクライアント/サーバ型通信が可能になる。
RESTと同様のAPI呼び出し方法としては、以前よりCORBA(Common Object Request Broker Architecture)やRPC(Remote Procedure Call)、SOAPなどさまざまな手順がある。だが、これらは高機能な代わりにいずれも複雑で、手軽さに欠けているため、幅広く利用されるには至っていない。
一方、RESTはURLを指定するだけでAPIを呼び出せる。例えば、Web版のTwitterで、ツイートの中から「Windows」を含むものを検索して表示するには以下のURLを呼び出す。
https://twitter.com/search?q=%22Windows%22
これと同じ検索をTwitter REST APIで実行するには、URLの一部を置き換えて以下のようにする。
https://api.twitter.com/1.1/search/tweets.json?q=%22Windows%22
このように、通常のWeb呼び出しと同様にして、APIを呼び出せる手軽さが大きな特徴だ。
利用が広がりつつあるREST API
スマートフォンやクラウドサービスの普及により、ユーザーインタフェース部分を担うフロントエンドと、サービス本体となるバックエンドの処理を分離して、両者をAPIで連携させるサービスが一般化してきた。例えばTwitterのつぶやきはサーバ側で管理されているので、スマートフォンやWebブラウザのどこからアクセスしても、同じように使うことができる。
具体的には、以下のようなケースで、APIを利用したアプリケーション連携が一般化している。
- TwitterやAmazonなど、Webアプリケーションの機能や情報をAPIとして公開するもの
- Facebookの「いいね」ボタンなどのウィジット(注:FacebookのAPIは、現在はRESTをベースにした新しいGraph APIに移行中)
- サーバ側で多くの機能を実装し、それらを複数の端末から同様にアクセスできるようにしたスマートフォンアプリケーション
- バックグラウンドで、非同期にデータを読み込むことで、操作性を高めたWebアプリケーション
- 社内システムの連携
インターネットを利用する、こうしたAPI連携システムにおいて、手軽なRESTが広く使われるようになってきた。
RESTは軽量なWebサービス
RESTによるWebサービスの実装は軽量で、以下のような特徴がある。
- 特定のプラットフォーム(OS)に依存しない
- 特定の言語に依存しない(Java、C#、Perlなど、さまざまな言語で利用できる)
- HTTPなどのインターネット標準プロトコルを利用
- ファイアウォールがある環境でも容易に利用できる
ただしREST自体には、セキュリティや暗号化、セッション管理、サービス品質の管理(QoS:Quality of Service)などの機能は組み込まれていない。例えば暗号化が必要なら、HTTPSを組み合わせるといった対策が別途必要になる。
RESTによるデータ取得API呼び出しを図にすると次のようになる。クライアント側アプリケーションのAPIのリクエストは、HTTP GETによりサーバ側に送られる。前述した通り、呼び出すAPIはURLとして指定する。
リクエストを受けたサーバ側では、必要な処理を行った後、テキスト形式のデータで、レスポンス(応答)を返す。
RESTful API設計のガイドライン
RESTは設計原則にすぎないため、どのような機能/APIを実装すればRESTに準拠したことになるのかは明確には決まっていない。それでもいくつか必須とされる要件がある。それは例えば次のようなものである。
●ステートレスなプロトコル体系の使用
クライアントからサーバへの要求やその応答は、それぞれ単独で完結していること。もし要求や応答が複数のコマンドに分かれていると、セッション状態の管理や不完全な要求/応答への対処が必要になる。ステートレスな設計なら要求を処理してすぐに応答を返せばよいので、スケーラビリティを向上させやすいなどの利点がある。
●リソースを一意に識別するURL(URI)設計
操作対象のリソースをいつでも同じ手順で参照・特定できるように、また人間が直感的に理解できるように、階層的にURLを定義すること。さらに静的なURLにしていつでも同じように参照できるようにしたり、サーバサイドのテクノロジーを表すような拡張子(.jspや.aspなど)情報などは排除して、将来も変わらずアクセスできるようにするなどの配慮をすること。
●HTTPで定義されているメソッドの使用
リソースの操作のためにはHTTPで定義されているメソッドを常に適切に使うこと。サーバ上にリソースを作成するにはPOSTを、リソースを取得するにはGETを、リソースの状態を変更/更新するにはPUTを、削除するにはDELETEを、それぞれ利用すること。
●XMLやJSON形式による要求や応答の送信
XMLやJSON(JavaScript Object Notation:JavaScript言語の一部をベースに作られた軽量なデータ交換フォーマット)形式は、構造的なデータや、(データの中に別のデータを含む)階層的なデータを表現するために十分な機能を持っているし、人間にとっても可読性が高く、扱いやすい。
これら以外にも、例えばAPIのバージョン番号の付け方やエラーの返し方、名前の付け方など、考慮しなければならない要件がいくつかある。
一般的にはWeb APIと呼ばれることも
これまで説明したように、「HTTPを利用してJSONやXMLのデータを取得する手軽なインタフェース」という意味で、RESTや、実装されたAPIをREST APIと呼ぶことが多い。しかしRESTを提唱したRoy Fielding氏の定義はこれよりも厳密で、REST APIでは適用範囲が広すぎるという指摘もある。このためインターネットを介したアプリケーション連携では、「Web API」と表記するほうが適切だという意見もある。
■関連リンク
- Twitter REST API(twitter.com)
- GitHub API(github.com)
- ASP.NET Web API 2(マイクロソフトMSDNサイト)
- 連載「ASP.NET Web API 入門」(Insider.NET)
※「ASP.NET Web API」は、Windows OSでRESTfulなHTTPサービスを構築するためのフレームワーク。
Copyright© Digital Advantage Corp. All Rights Reserved.