You don't need API version 2
周回遅れ感が半端ないけどバージョニング関連で色々読んで・聞いて思ったことを書く。
- APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight
- Kazuho's Weblog: 拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について
- Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima)
- rest - Best practices for API versioning? - Stack Overflow
- RESTfulなサービスのバージョンングから得られた知見
RESTとバージョニング
基本的にいわゆる狭義のRESTとAPIのバージョニングは何も関係ない。強いて言えば、HATEOASはバージョニングにも使えるよ、というのがREST信者の主張であるものの、それが正しい（というか実用的）かどうかはまだよくわからない状況だと思う。
なので、APIをRESTfulにするためにはバージョニングはどうあるべきかという議論はそもそも斜め上で、どうでもいい話かと。
一方でREST API（僕はこの呼び方嫌いだけど）のバージョニングはどうあるべきかというのは、設計論として当然あり、そこは実装との兼ね合いもありいろいろ難しい。
APIのバージョン設計論
奥さんが書いてる通りだと思う。
破壊的変更（breaking changes）はなるべく避ける。ここでいう破壊的変更というのは必須のパラメータを増やすとか、デフォルト値を変更するとか、パラメータ名を変更するとか、特定のAPIを廃止するとか、そういった以前のクライアントがそのまま使えない変更のことを指す。
この辺は最近はJSONを使っていればそれほど難しいことなく実装できる（ややこしいことに興味がある人は「xsd upa」で検索してみよう）。
一方で、最初からv2を見据えてURIにわざわざv1とか入れちゃうのはムダな工数と負債を最初から抱えてしまうように感じる。なるべく破壊的変更は入れずにバージョンを上げるべき。どうしても変更が必要であれば、江島方式もあるし、宮川方式もあるし、奥方式もある。個人的にはv2を見越しちゃうことを「心配性症候群」あるいは「皮算用症候群」と呼んでいる。ちゃんと設計されたAPIは寿命がとても長いし、どうしても本当に破壊的変更を加えたくなったらそれは新APIなのだと思う。そしてWeb APIの場合は名前空間を分ける方法はいくらでもある。
Dynamic Scripting Platformについて
Rebuild.fm#35 を聞いて初めて知ったけど、netflix にdynamic scripting platformというのがあるのですね。RESTでいうところのCode on demandのクラサバ逆転版みたいなもののようだ。こういうのが欲しいというのはよくわかるしかっこいい。いろいろ熱そう。
要はストアドプロシージャじゃねーの、と突っ込まれそうだけど、SQLのスコープとWeb APIのスコープは違うので、課題もいろいろ異なると思われる。
その他
rebuild.fmを聞いてたらなんかmiyagawaさんが思いの外REST厨っぽい発言をしてて、思わずニヤニヤしてしまった。勝手にmiyagawa氏はもっとプラクティカルでカジュアルな嗜好なのかと想像してたけど、メディアタイプ厨的発言をしてたりとかわいい一面が。ちなみに僕はメディアタイプにバージョン番号を含めるのは本当にいいのかはまだよくわからないです。
あと江島さんのブログエントリは炎上成分が高かったみたいだけど、実装・運用経験に裏打ちされた発言で説得力があると感じた。やっぱり動いているプログラムが一番強い。
