ミルクボーイが REST API を説明したら
序章
駒場「最近、うちのおかんがシステム開発に興味を持っててなぁ、名前は忘れたらしいんやけど、色んなクラウドサービスのインターフェースになっていて、アプリケーション間連携にすごく役立てられるものを取り入れてるところがあるらしいんやわ〜。」
内海「そんなもんREST APIに決まってるがなぁ! 今やクラウドサービス連携に必須の要素、インターフェースと言えば、REST API。ロイ・フィールディングが提唱し、WEBやURIの特性・HTTPプロトコルを最大限に活かしたアプリケーションプログラミングインターフェースのスタンダードになっているREST APIに決まってるがなぁ。」
すべての情報(リソース)に適用できる「よく定義された操作」のセット
駒場「最初、オレもそう思たんやけどな、なんでもHTTP Body にInsertとかCreateとか入ってるらしいんやわ。」
内海「ほなぁ、REST APIちゃうかぁ…。REST API は HTTP メソッドで予め定義されているGETやPOSTを利用するのがスタンダードやからなぁ。それはRPCのプロトコルであるSOAPとかちゃうんの? おかん、他にもなんか言うてなかったかぁ。」
リソースを一意に識別する
駒場「そー言えば、URIを意識して作ってるって言うてたわ。」
内海「ほな、REST APIやないのぉ。 REST API ってことは、リソースを一意に識別するためのURIが重要で、users や products とかの名詞で構成するのがスタンダードやからなぁ。やっぱ、REST API やろぉ。」
駒場「オレもそう思たんやけどな、URI にも getUsers とか postPoroduct とか動詞が含まれていて、全部POSTリクエストで実装しているらしいねん。」
内海「ほな、REST API と違うかぁ。リソースは一意になっても、HTTPのメソッドを活用してないからなぁ。やっぱりRPCのプロトコルのSOAPとかちゃうんの? 他にもなんか言うてなかったぁ?」
ステートレスなクライアント/サーバープロトコル
駒場「おかんが言うにはな、ステートレスでやっているらしいわ。」
内海「ほな、REST API に決まってるがなぁ。REST APIは、HTTPメッセージの一つ一つが、そのリクエスト(メッセージ)を理解するために必要な全ての情報を含んでメッセージ間におけるセッション状態を記憶しておく必要がないようにしているから、やっぱREST APIやろぉ。」
駒場「オレもそう思たんやけどな、なぜか商品情報登録のために3つのリクエストを順番に実行しないといけないらしいねん。」
内海「ほなぁ、REST APIとはちゃうなぁ。 サーバーとクライアントの通信で状態を管理してしまったら、サービスがスケールしづらくなるし信頼性、結合度の点でもよくないもんなぁ。やっぱりREST API とちゃうがなぁ。」
アプリケーションの情報と状態遷移の両方を扱うことができる「ハイパーメディアの使用」
駒場「おかんが言うにはな、 ハイパーメディア ってゆーのを取り入れているらしいわ。」
内海「そしたら、やっぱりREST APIやろぉ。通常のWebサイトと同じようにハイパーメディアでリソース間の繋がりが構成されていて、クライアントはリソース名をしらなくても辿ることができるようになっているんは常識やもんなぁ。やっぱ、REST APIやろぉ。」
駒場「オレもそう思たんやけどな、Excel 仕様書にリンクを書くってゆーてたわ。」
内海「ほな、絶対にREST APIとちゃうがなぁ! ハイパーメディアといえばハイパーメディアだけど、それはREST APIじゃなくてきっと神EXCELやがなぁ!」
結末
駒場「おとんがゆーにはな、GraphQLちゃうか? ってゆーねん。」
内海「それも絶対ちゃうやろ!Facebookに失礼や! もうええわ!」
ありがとうございましたー
(ご意見、ここが違うんじゃね? などお待ちしています。)