Love PG , Liquor & Music

プログラマー備忘録やお酒や音楽

RESTfulについてのメモ(SOAPと同じじゃないの?)

最近の開発では設計思想、デザインパターンをあまり考慮しなくても
フレームワークが包括しててくれてたりするので特段意識することは少なくなってきていますが、
・使ってるフレームワークがどういう思想で設計されてる

 とか、
・他にはどういう思想で設計されたものがあるのか

 とか、
・自分で作ったり拡張するときににはどう作ればいいか

とか、知っておかないとできないことが多くなります。その都度悩んで自己流にやるのは効率悪い。せっかく頭のいい人が作った設計思想があるのならこれに乗っかるしかないっ!というところでいろいろ知ることによって選択の余地も広がるので
設計思想とかそこらへんを少し勉強しておこうかなーっとちょっと調べたました。

 

まず、なんで最初にRESTfulを選んだかというと、
WEBプログラマーやってたのに知らないのwwwと某プログラマーに煽られたので
この悔しさが少しでもバネになればと思ったからです。
調べてみるとこれまで何気なく使ってたケースが多々ありました。
ただこれがRESTに沿って作られていることを知らなかっただけです。(言い訳)
まあ、意識してきちんと作るのとなんとなくな感じで作っていくのでは雲泥の差がりますので、いい機会と思ってしっかりと理解しようと思います。

 

RESTってなに?

Repreentational State Transfer
翻訳すると、具象的な状態に移す?
みたいな感じでしょうか。全然意味がわかりません。

Wikipediaには以下のようにありました。

・FieldingのRESTアーキテクチャスタイルの原則に合わせたWebサービスシステム。
・RPCスタイルに合わせた簡易な XML+HTTP インターフェイスを採用したシステム

うーん英語ばかりでわからない。ちなみにFieldingってのはREST提唱した人の名前で

 RPC(Remote Procedure Callの略)で、要は別のコンピュータのに存在する処理を使用すること。

つまりどういうこと?

自分なりに解釈してみたのが↓
・WEB上にサービスを公開するときのルール。
みたいな感じです。

ちなみに前回記載したAOuthの実装に関してもこのルールに沿って実装されています。たぶん。

じゃあ、RESTfulはなに?

RESTfulはREST設計思想の仕様を満たしているサービスとのことを指します。
REST(のルール)をfull(満たしている)ってことなんですね。

Heartfullとかと似た感じでしょう。

ちなみにRESTを熱心に支持する人を、RESTafariansと呼んだりするらしいです。

 

どうゆう感じで使われているの?

RESTは前途したとおり設計思想であって技術ではありません。
ので、RESTFulなAPIJavaとかRubyとかPHPとかいろいろな言語で実装できます。

ルールさえ守ってればそれでいいのです。

たとえば、ユーザーIDが10のユーザー情報を取得するAPIを公開するとしたらこんなURIで取得できるようになります。

GET example.com/users/10

でこれをRequestするとXMLとかJSON形式でResponseが返ってきます。

そして、そのユーザーが持っている本(Book)リストをとりたいときはこんな感じで取れます。

GET example.com/users/10/books

全ユーザーが持っている本から彼岸島の情報取得したい場合は

GET example.com/users/books?search=彼岸島

もしくは

GET example.com/users/books/title/彼岸島

とかこんな感じで取れるようになります。

これを実現できれば特になにで実装しようとOKってわけです。

つまり、RESTFulはリソース単位でURIがついたような構造になるってことです。

JavaだとPlayとかJAX-RSRubyだと今勉強中のRailsなんかがこの設計思想をサポートしてます。

 

どこで使われてるの?

以下は実際にFacebookが公開しているRest APIになります。
FacebookはデータをGraph形式でリレーションしているので、
Graph APIなんて呼ばれたりします。

たとえば

こんな感じでよんであげると、自分のプロフィール画像へのリダイレクトURLが取得できます。

GET graph.facebook.com/facebook/picture?redirect=true

んで、こうすると渡したオブジェクトから自分のタイムラインに投稿できたりします。

POST graph.facebook.com/me/feed/message=test&access_token=ASDFGHJ

試してはないですが。

https://developers.facebook.com/docs/graph-api

 

どんなルールがあるの?

URIのルール
まずURIのルールはざっくり以下のような感じになります。
シンプルでわかりやすくというのがURI制定の指針になっているので、
  GET /users 一覧を取得する
  GET /users/1 id=1のものを取得する
  POST /users 新規に追加する
  PUT /users/1 id=1のものを更新する
  DELETE /users/1 id=1のものを削除する
という感じになります。

users(複数形)、user(単数形)それぞれ意味があり、重要になってきます。

 

メソッドのルール
リソースへのアクセスは登録・更新・削除・参照のみと制限されているのでおのずとシンプルな作りになると思います。
といっても、/updateとか/showとかそれぞれにメソッドを設けるのではなく、上に挙げたHTTPメソッド(GET、POSTなど)に依存させるようなルーティングが必要になります。

で、メソッドは、いつ、どんなアプリやシステムから呼ばれても必ず同じ値を返す必要があります。そのために必要なパラメータはHttpRequestですべて渡してあげる必要があります。要はステートに依存するような処理は極力さけなさいねってういうことです。どうしてもな時は(僕は)しょうがないと思います。

 返却値はControllerよりXMLもしくはJSON、HTMLなど形式で返却します。値の設定はVIEWで独立させるようにしておきます。

 

で、本題

SOAPと同じじゃないの?

ってとこですが、実装だけ見ればWEBに公開された処理を呼び出してデータをJSONとかXMLでやりとりするってとこだけとると同じです。よくSOAPとRSETは同じようなものと聞きますが、サッカーと野球、どっちもボール使うので同じ球技っていうレベルの同じです。

 

もちろん、ルールが違うのでそれぞれに向き不向きが出てきます。

SOAP、RESTもそういう関係です。

よく使われているのが、

 ・スマフォ⇔サーバーはREST

 ・サーバー間はSOAP

なんかになります。

なので、両方知ったうえで作ろうとしているものにあったものを選定するのが一番じゃないかなーと思いました。

僕は特にどちらも支持しないのでRESTafariansよりRastafariansのほうが向いているのかなとか感じた1日でした。

サービス ステーション: REST の詳細