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アプリケーション
• 社内システムの連携

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呼び出しの構成
クライアントからの要求は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」と表記するほうが適切だという意見もある。

■関連リンク

• 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サービスを構築するためのフレームワーク。

「Tech Basics／Keyword」