#mozaicfm REST を聴いての感想
mozaic.fmでRESTの回が企画されているということを、API Meetup #1 のときに yohei さんから直接聞いていたのですが、ついにそれが公開されたので、喜び勇んで聴きました。
断片的に感想をツイートしたので、そのまとめです。
RESTの何が重要なのか
さすがの t_wada さん。アーキテクチャとしてもそうだし、アプリケーションフレームワークも「適切な制約」を設けることで設計のコストが下がる、という話の流れでした。
“Constraints are liberating”「制約は自由をもたらす」は僕が好きな言葉ですが、これを知ったのはDHHのRubyKaigi 2006の講演からです。（初出はどこか別のところなのかも？）
RESTの流行
原理主義者的発言をするなら、「REST API」と謳って世に出たWeb APIはただのJSON/XML over HTTPばかりじゃないか、ともいえるわけです。Richardson Maturity ModelでいうLevel 1かLevel 2のものばかり。
流行り始めの頃はもっとひどくて、平気でLevel 0のがあったので、だいぶ良くなったわけですが。
これは話中にも出ていたリアルタイムWebにもあてはまることで、WebSocketやWebRTCなどが開発されたのは、まさに課題の解決にRESTアーキテクチャが合わなかったからだと思います。
ただ少し話がずれますが、たとえばWebSocketは制約がなさすぎるため、相互運用の需要が出てきたら今後問題になるんじゃないかな、と懸念しています。
初期の頃WebSocket上にRESTを持ち込もうという動きがありましたが、当然のごとくうまくいきませんでした。
Web APIのバージョニング
Golangのパッケージバージョニングの話は、 yohei さんの通りちょっとレイヤーが違う話だと思いましたが、 Jxckさんの「バージョンがないものに後からバージョンを入れるのは困難」というのは、わかる気がしました。
とはいえ、Web APIの文脈でバージョンを語るには「バージョンとは何か」「バージョンの切り替え方」などをクライアントに理解させなければいけません。それがなければ、バージョンが変わったときにただクライアントは動かなくなるだけです。
非互換な変更がない（拡張など）なら、クライアントはバージョンを意識する必要はありません。そして、クライアントが壊れず正常に動き続けることが一番大事なことです。
バージョニング自体よりむしろ、やむを得ずバージョニングを行ったときに、API利用者を誘導する移行プロセスのノウハウのほうが重要かもしれません。
「Webを支える技術」を改訂するとしたら？
JSONにリンクがない問題、今のところメディアタイプとLINKヘッダという2つの解決策がありますが、どちらも決め手に欠けます。でもそれで行くしかないでしょう。ビッグプレイヤーがよいデファクトスタンダードを提示してくれることを期待します。改訂のころにはコンセンサスが得られているかも？（いてほしい）
