RESTTech Basics/Keyword

RESTとは、広く普及したWebのインフラをそのまま利用して、簡易な手順でアクセスを可能にした、Webサービス向けのソフトウェア設計アーキテクチャ。

» 2016年01月13日 05時00分 公開
[小川誉久, 打越浩幸デジタルアドバンテージ]
Tech Basics/Keyword
Windows Server Insider


「Tech Basics/Keyword」のインデックス

連載目次

 「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を公開している。

 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アプリケーション
  • 社内システムの連携
REST APIによる連携 REST APIによる連携
REST 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として指定する。

RESTによるAPI呼び出しの構成 RESTによるAPI呼び出しの構成
クライアントからの要求はHTTP GETでサーバに送られ、処理後、結果はXMLやJSONなどでクライアントへ返される。

 リクエストを受けたサーバ側では、必要な処理を行った後、テキスト形式のデータで、レスポンス(応答)を返す。

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」と表記するほうが適切だという意見もある。

■関連リンク


「Tech Basics/Keyword」のインデックス

Tech Basics/Keyword

Copyright© Digital Advantage Corp. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。