SOAと「つなぐ」技術 第5回:SOAをとりまく「つなぐ技術」 - REST

Avatar
dstn

マーケティング企画部の渡辺です。

今回は、前回のWebサービスの説明に引き続いて、最近のWebサービスで利用されることが多くなっている、RESTスタイルのWebサービスについて説明をします。

SOAPとREST

Webサービスには「SOAP」(Simple Object Access Protocolの略)と呼ばれるWebサービス登場当初から利用されているものと、最近利用されることが多くなった「REST」(Representational State Transferの略)と呼ばれるスタイルのものがあります。SOAPはWebサービス登場時から使われているもので、RESTは最近になって広く使われるようになりつつあるものです。 

しかし、次の点では大きく違います。複雑になりがちなSOAPと、単純にすることを思想としているRESTの違いです。 

SOAPは通信でやり取りするものをXMLで包み込んで送受信します。つまり、具体的にどういう使われ方になるかは、送受信するXML次第です。しかし、SOAPは複雑な使われ方をすることがもともと多いことがあり、複雑な用途に向いている傾向があります。 

そのためSOAPによるWebサービスは、Web上で使われるWebサービスなどでは不必要に複雑すぎることが多くありました。そこで、シンプルなWebサービスを求めるニーズに応えて使われるようになってきたのが、新しいWebサービスのスタイルである「REST」です。 

思想としてのREST

RESTは、二つの意味で使われています。

一つは、「考え方(思想)としてのREST」です。もう一つは、そのような考え方に基づいて最近使われるようになった「Webサービスの設計スタイル」のことを「REST」と呼ぶ場合です。

一般的にはRESTという言葉が使われる場合には後者を指すことが多いように思いますが、まずは後者について理解するためにも前者について説明をします。

RESTとは "Representational State Transfer" の略で、Roy Fielding氏によって提唱された、良い通信プロトコルを作るための設計原則です。

Roy Fielding氏はHTTPプロトコルの考案者の一人です。HTTPプロトコルはWebブラウザがインターネットからデータを取ってくる際に使われている通信プロトコルで(この記事をご覧になる際にも使われているものです)、まさにインターネットそのものを支えている技術と言えるものです。RESTはそんなHTTPプロトコルの設計思想が反映された考え方です。

RESTは、以下のような四つの設計原則からなります。

  • ステートレスなクライアント/サーバプロトコル 
  • すべての情報 (リソース) に適用できる「よく定義された操作」のセット 
  • リソースを一意に識別する「汎用的な構文」 
  • アプリケーションの情報と状態遷移の両方を扱うことができる「ハイパーメディアの使用」

ステートレスなクライアント/サーバプロトコル

ステートレスとは、通信が「状態を持たない」ことを言います。今受け取ったメッセージの解釈は今受け取ったメッセージの内容だけで完結しており、以前に受け取ったメッセージの内容に依存しないこと、たとえばセッションなどを用いないことを言います。

ステートレスにすることで処理がシンプルになります、今受け取ったメッセージだけで今すべきことが解るからです。また、処理続行のために状態を保持する必要がなくなるために大量の情報の処理も容易になります。この考え方はHTTPプロトコルの設計でも取り入れられています。

すべての情報 (リソース) に適用できる「よく定義された操作」のセット

これは、多くの処理や呼び出しで広く汎用的に用いるメソッドを利用することを言います。

例えば、処理に対応して以下のようなメソッドを作りこむ方法はREST的では「ありません」

  • getUsersList() 
  • setUserName() 
  • setUserPassword() 
  • createUser() 
  • (などなど)

処理対象や処理内容に対応してメソッドを個別に作るのではなく、すべての呼び出しで共通の語彙を用いるようにします。その代表例は、やはりHTTPプロトコルです。HTTP 1.1では八つのメソッドが定義されていますが、その中で主に使われているのは以下の四つのメソッドになります。

  • GET 
  • POST 
  • PUT 
  • DELETE

リソースを一意に識別する「汎用的な構文」

これは、様々なリソースを一つの書き方で一意に指定できるようになっていることです。

例としては、やはりHTTPが利用するURL(URI)です。URLではあるリソース、たとえばHTMLファイルや画像ファイルなどを、世界中のどこにあるものであっても、たった一つの指定方法で曖昧さなく個別に指定することができます。

利用者からすると、一つの書き方を覚えてそれで場所を指定するだけで、どんなリソースでも指定できることになります。

アプリケーションの情報と状態遷移の両方を扱うことができる「ハイパーメディアの使用」

これは、情報を返す手段とナビゲーションの手段を同じハイパーメディアで提供して、簡単に済ませましょうという提案です。

ハイパーメディアとは、情報を受け取る手段と、他のリソースへの移動手段(ハイパーリンク)が一緒になったもののことです。つまり、ウェブサイトのHTMLのようなもののことです。理解が難しければ、HTMLのことだと思って差し支えありません。

呼び出しの結果、データを戻す場合があったり、移動手段を戻す場合があったりしても、それぞれ別の方法を用いるのではなく、コンテンツとリンクが入った「同じ入れ物」で結果を返すようにしましょう、という考え方です。例えば、データの場合は表組みされたデータを返し、移動先を返したい場合はリンク(ハイパーリンク)のリストを返す、などです。 

WebサービスとしてのREST

WebサービスのスタイルとしてのRESTとは、以下のようにRESTの四つの設計原則に従い、Webサービスを実現したものです 

ステートレスなクライアント/サーバプロトコル 

HTTPをそのまま使います。その結果ステートレスとなります。また、キャッシュやロードバランサ―などのHTTPのインフラで使われている様々な工夫を、RESTでもそのまま使うことも出来ます。 

すべての情報 (リソース) に適用できる「よく定義された操作」のセット 

HTTPの代表的な四つの語彙をそのまま使います。 

  • GET:リソースのコピーをもらう 
  • PUT:リソースを更新する(投稿したデータで置き換える) 
  • DELETE:リソースの削除 
  • POST:副作用のあるアクション(例:印刷する)、あるいはその他全て(例:新規作成) 

リソースを一意に識別する「汎用的な構文」 

何に対するリクエストなのかをURLで指定します。URLが同じなら同じリソースに対するアクセスです。違うなら違うリソースへのアクセスです。とても明快です。 

アプリケーションの情報と状態遷移の両方を扱うことができる「ハイパーメディアの使用」

XMLやJSONを用いて、何でもそれに格納します。

 

以上のように、RESTとはシンプルさを重視したWebサービスのスタイルであると言えます。

シンプルさを重視する視点で考えると、XMLも無用に複雑なフォーマットに思えてきます。そこでRESTではXMLではなく、よりシンプルでWeb上での処理に親和性がある「JSON」が用いられるようになってきています。

JSON/REST

JSONは元々はJavaScriptでのデータ表現です。JavaScriptでの処理が容易であるだけでなく、書式が簡単なため、XMLよりもデータサイズが少し小さくなり、他の言語でも読み取りや書き出しの処理が簡単にできます。

以下、JSONの例です。見てわかる通りXMLよりもシンプルです。

{
  "author": {
  "age": 36,
    "name": "Taro Yamada"
  },
  "book": {
    "price": 3000,
    "title": "Essential EAI"
  }

RESTかSOAPか

Webサービスでは、RESTが良く利用されるようになってきています。ご覧いただいた通りシンプルで解りやすいこともあり、クラウド系のサービスのAPIとしてはJSON/RESTが採用されることが多くなってきています。 

今後のWebサービスでは、REST、特にJSON/RESTの利用が進むことになるでしょう。 

しかしながら、複雑な処理を実現しなければならない場合はSOAPの方が適切な場面もあるでしょう。SOAPは例えば基幹システムで良く利用されるような、難しいやり取りが標準化されていることがあり、ライブラリを入れるだけで複雑なことがすぐに出来るようになっていることがあります。 

SOAPの複雑さが求められる状況では当然SOAPの出番であり、RESTで同じようなことをすると大変になることが多いのではないかと思います。よって、RESTを用いるかSOAPを用いるかは、今後も状況次第だと思います。 

おわりに

今回は、Webサービスとして採用されるようになってきている「REST」について説明をしました。

RESTが受け入れられ、利用されるようになった理由としては、SOAPがニーズに対して複雑すぎたということもあるでしょうが、HTTPプロトコルの設計に対するリスペクトや、思想としてのRESTに共感した人が多かったこともあると思います。

物事をより良く作りあげるための指針として、RESTの考え方は様々な場合に参考になるのではないかと思います。例えば、Webサービスを使わない場合でも、さまざまなものを設計する際に、それらをよりよく設計するための指針となるのではないかと思います。

また、RESTの設計思想を解っていれば、RESTfulなWebサービスを利用する際にも、どのように使えばよいか理解しやすくなるのではないかと思います。

次回は、トランザクションについて説明をする予定です。

コメント

ログインしてコメントを残してください。

Powered by Zendesk