こんにちは！山下というものです！
今日は祝日なのですが、ふと、RESTって言う言葉が頭によぎりまして、
なんとなくは、理解しているけれど、改めて復習しておきたいなと思い、簡単にまとめてみました。
RESTの言葉の意味。
このRESTという単語は、
- 『Re』Representational: 代表的な
- 『S』Staate: 状態
- 『T』Transfer: 転送
これらの文字を取って『REST』と言います。
代表的な 状態 転送
なんぞや...ってならうかもですね。
なんとなくこんなものだと覚えておく程度で良いと思います。
REST設計について
- アドレス可能性
- 統一インターフェース
- ステートレス性
- 接続性
この四つが満たされてREST設計となります。
アドレス可能性
リソースをURIで一意に識別してデータが返ってくる、といったように、
それぞれの情報ごとに場所や名前を識別できるように表現できる性質のこと。
URIとリソースは直感的に対応させた方が良い
さらに、URIは構造的で、かつその構造は予測可能な方法で区別されることが好ましい。
例
http://gennzei.com/search/dog
上記は、犬について調べてるんだぁ。と一発でわかりますが、
1つのAPIの中で、
http://gennzei.com/i-want-to-info/cat
この二つが扱われたらどうでしょう？かなり気持ち悪いですね。
なので、/search/dog としたなら/search/cat としたならにすべきなのです。
統一インターフェース
インターフェースって何かと何かを繋ぐもの。という意味ですよね。
例えば、GET POST PUT DELETEといったメソッドがあります。
クライアントがサーバーに対して『税金についての情報がほしいよ～』といった時には、一貫してGETを使いますし、『このデータを更新したい！』ってときはPUTを使い、削除したければDELETEを使います。
あ、POSTは、データを追加したい！みたいなときに使います。
こうしたメソッドを、目的によって使いまわそうよ。ということで、この四つのメソッドを一貫して使用するわけで、これらを統一インターフェースと呼びます。
基本サーバーからデータを返すときはJSON形式で返すのが主流となっています。
ステートレス性
ステートレスってなんぞや。
- Stateless=状態を持たない
という意味があります。lessは無い。という意味を持ちますね。
様するに、クライアントのState(状態)を持たない。ということです。
逆の言葉は、Statefull(ステートフル)といって、クライアントの状態を持つことになります。
普通に考えると、ステートフルな方がクライアントの状態、情報をあらかじめ持っているのだから、一々ステートフルな状態にしていたら手間じゃない？と思うかもしれません。
ですが、このステートフルな設計だと、クライアント毎の状態を考慮した処理を返さなければならず、とても、大変ですし、シンプルではなくなってしまいます。なのであらかじめ。最初から状態、情報を保持せずに、URIに沿って忠実に処理を行い、結果を返す方がシンプルですし、拡張性も担保されるわけです。
ログイン情報なんかは、情報を持っていた方が良いことはありますが、
RESTの基本はステートレスです。
簡潔にまとめると、ステートレス性は、
全てのリクエストが個別に処理され、リクエスト間の依存性がないことを指します。
接続性
コネクタリビティと言いますね。「リソースに含まれるリンクをもとに別のリソースに接続可能となる(遷移可能となる)性質のこと」です。
接続性は、他の 3 つの特性を兼ね備えた上で、
関連するリソースの URI をお互いに表現することを指します。
この特性によって、クライアント側が URI の生成ルールを把握する必要がなく、関連するリソースにアクセスすることが可能になります。
この特性がない場合、URI を知る術がなくリソースにたどり着けません。
ROA（リソース指向アーキテクチャ）
これら4つの特性は、ROAと呼ばれる設計思想の中のお話です。
RESTはこのROAを提唱しています。
ROA は「リソース」に重点を置いていて、リソースを URI で一意に表現し、リソースの状態を HTTP メソッドで操作することで、API を理解しやすくなり可読性が高まります。
終わり
なんとなく完結に調べて記事にしてみました。
初心者だったりが呑み込みやすいように抜粋して書きましたが、
何となくこんなものなんだ～と理解してくれると嬉しいです。