RESTって気軽にGETでデータ取得できるものじゃないの!?

【この記事の所要時間 : 約 3 分

WebサービスAPIを利用してちょこちょこサイトを作っていると、RESTというのが、サーバ間でデータを取得するのに、GETで気軽に使えるものというくらいの認識しかありませんでしたが、
REST 入門
を読んでちょっと認識をあらためました。
とはいっても完全に理解しているわけではないのですが・・・

今回の POST, PUT, DELETE と、前回の GET はある点で大きく異なります。それは GET がリソースの状態に影響を与えないのに対して、それ以外の三つの動詞がリソースの状態に何らかの影響を与える可能性がある点です。このような性質を副作用(side effect)といいます。副作用のない GET はキャッシュという大きな可能性を持つことになります。キャッシュについては機会があれば説明しようと思います。

これまでの内容をまとめると以下のようになります。

* GET はリソースを取得するメソッド
* PUT はリソースを更新するメソッド
* DELETE はリソースを削除するメソッド
* POST はリソースを新規作成するメソッド
* GET はリソースに副作用を与えない

REST では、リソースを操作するインターフェースにはこの四つのメソッドしかありません。 getXx() も setXx() も startXx() も createXx() もないのです。これは REST アーキテクチャスタイルの持つ大きな制約のひとつ、統一インターフェース(uniform interface)です。

というのは、SQLと比較すると、
GET → SELECT
PUT → UPDATE
DELETE → DELETE
POST → INSERT
ということで、DMLしか使えないというかこれしかさせないという仕様なんですね。
Amazonやリクルートなどが公開しているWebサービスAPIでは、REST方式の中で「GET」しか許さないようにさらに限定しているということなんでしょうね。
機能間のデータ連携などに利用されるWebサービスでは、GETだけでなく、そのほかの3つのメソッドも許可して・・・という具合になるんでしょうね。じゃあなぜみんなSOAPをやめてRESTにしないの?という疑問はありますね。SOAPについても書かれているのですが、まだまだ理解が足りないようで。
スケーラビリティやそのほかのメリットがあるんでしょうね。とはいいつつREST入門では、REST vs SOAPという対比について否定的な見方をしていますが。
とりあえず頭の中に残しておけば、発酵して理解できる日がくるかもしれません。

スポンサーリンク
レクタングル(大)広告
  • このエントリーをはてなブックマークに追加
スポンサーリンク
レクタングル(大)広告

コメントをどうぞ

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください