REST API
REST APIとはRESTfulなAPIのことである。
RESTfulとは
REpresentational State Transferの略称で、分散型システムにおける設計原則群である。一般では４つの原則(思想)に則り設計することである。
FWとかではなく、オブジェクト指向プログラミングのような設計概念的なものと同等。
４つの原則とは
以下の４つのことをいう。
- Uniform Interface(統一インターフェイス)
- Addressability(アドレス可能性)
- Stateless(ステートレス)
- Conecctability(接続性)
実は、RESTを発表した論文には”原則”という具体的な内容は記述されておらず、RESTという ”アーキテクチャーを導き出したプロセス”という表題で６つ紹介されている。
内容は以下の通りである。
- Client-Server（クライアント-サーバー）
- Stateless（ステートレス）
- Cache（キャッシュ）
- Uniform Interface（統一したインターフェース）
- Layered System（階層システム）
- Code-On-Demand（オンデマンドのコード）
RESTはロイ・フィールディング氏の原著論文「Architectural Styles and the Design of Network-based Software Architectures」（2000年発表）によって世に広まることとなる。先ほどの”4つの原則”というのは発表から長年の月日が経つことで、現在に合わせてフィルタリングされたものではないか？と個人的に思っているが……。
統一インターフェイス(Uniform Interface)
apiにおけるインターフェイスとはHTTPメソッド[GET(抽出)・POST(入力)・PUT(更新)・DELETE(削除)など] を指す。
クライアントがインターフェイスに則りリクエストをサーバへ送る。そしてサーバは決められた形式(Json形式がもっぱらメジャーだが) で情報を返す…。
このように、リクエスト→レスポンスにおいて、毎度毎度フォーマットが変わったりせず、決められたフォーマットで統一して取引を行うことを統一インターフェイスと呼ぶ。
これにより、異なるブラウザでも同じような画面を表示できる・システムアーキテクチャが簡素化され、わかりやすくなる。
ただ、実際の論文中では統一インターフェイス内でも”４つの制約”がある。
- リソースの識別性
- 表現を用いたリソース操作性
- 自己記述メッセージ性
- アプリケーション状態エンジンとしてのハイパーメディア性(HATEOAS)
である。
Addressability(アドレス可能性)
※論文上はURIで説明されるがもっぱらURLを使用するので置換している。
提供する情報がURLを通して読めること。すべての情報はURLで表現される一意な識別子を保持していることである。
これは統一インターフェイスの４つの制約内の３つに類似していると思う。
提供する情報がURLを通して読めること≒リソースの識別性・自己記述メッセージ性があり、
すべての情報はURLで表現される一意な識別子を保持している≒表現を用いたリソース操作性(HTTPメソッド)があるとも言えるのではないか…..。
ここでいうリソースとは画像や人物といった物理的なものから、過去・未来・時間等、抽象的/概念的なものも当然含める。ブログ等でいえば投稿の”lists”や人物の”id”,最新の投稿”latest”とかもそうだ。
” https://blog.com/posts/latest ”というURLがあったらどうだろうか。どこにアクセスしているのかが見てわかると思う。
アドレス可能性といっているが個人的にはアドレス可読性と考えてもいいとも思う。
Stateless(ステートレス)
State = 状態である。Stateがlessなわけだから状態がないことをいう。つまり、サーバはリクエストだけでコンテキストを理解できることをいう。
これだとわかり難いため例え話をするが、一軒のバーがあるとしよう。
そこには一人のバーテンダー(サーバ)と一人の客(クライアント)が居るとする。
客がバーテンダーに対して「ブランデーをください」と注文をする。
すると、バーテンダーは客に対してブランデーを提供する。次の日、また同じ客が来てブランデーを注文する。バーテンダーはブランデーを提供する……。
これを何回も続けているとバーテンダーは「もうこの客はブランデーしか飲まない！」と思うだろう。
たとえ客が「いつものとオリーブをください」と注文をしたとしてもバーテンダーは【ブランデーとオリーブ】を提供するだろう。
このように、やりとりが過去から続いている状態のことをStateful = 状態がある という。
では、Statelessで例え話をしてみよう。
例にもれずバーテンダーと客が居て、ブランデーを注文し、提供するとしよう。ここまでは同じである。
だが、24時を跨いだ瞬間、バーテンダーは”なぞのちから”で前日の記憶を失った場合、次の日に同じ客がきたとして「いつものください」と言われてもバーテンダーは「いつものって・・・なんですか？そもそもあなたは誰ですか」となるだろう。
客はまた同じように「ブランデーをください」と注文をしないと、バーテンダーはブランデーを提供してはくれないのだ。
逆に言えば、これはやりとりが一回ごと完結しているとも見て取れるだろう。過去という状態を保持していないのだ。これをステートレスという。
RESTfulはステートレスであることを原則としている。システムでステートレスであればいいこととはなんだろうか。
これは、やりとりが過去のやりとりの影響を受けないので、エラーが発生した際も、単一のリクエストだけを見れば良いので回復が容易になるなどが挙げられる。
ステートフルな過去を含むと”前提”が出てくるため、複数のリクエストを監視することになる。エラーが発生した場合、回復が困難になるとは容易に想像がつくだろう。
Conecctability(接続性)
これはアプリケーション状態エンジンとしてのハイパーメディア性(HATEOAS)と同等である。
HATEOASとはHypermedia As The Engine Of Application Stateの略称であり、レスポンスに現在の状態を踏まえた関連するハイパーリンクが含まれていることをいう。つまり、１つのリンクから別の情報にリンクすることができ、RESTfulな同士であれば円滑に情報連携を行うことができる。
難しく聞こえるかもしれないが、いわゆる”WEB”そのものである。
RESTfulな設計レベル
最後に設計レベルを紹介して終わりにしようと思う。
設計レベルは四段階存在する。
- level 0
HTTPを使用している - level 1
リソースの概念を導入している
リソースごとにURLを分離している。 - level 2
HTTPの動詞を導入している
リソースに対してHTTPメソッドを使ったCRUD操作が行われている - level 3
HATEOASの概念を導入している
レスポンスに現在の状態に関するハイパーリンクが含まれている。
level 3まで設計をして初めてRESTfulと呼べるようになるのだ。