ThriftとかProtocolBufferとか
自分はREST信者だけど、昨日、「RESTに固執せずThriftとかどうよ」という話をもらった。Thriftとか名前以外あんまり知らなかったので、一応２０分ほどWebで調べてみた。結論からいうと、「やっぱりあまり興味を持てない」と思った。
ThriftとかProtocol Bufferのいいところって、
ってところだと理解した。が、とりあえずあまり魅力は感じなかった。なぜか。
- 1を突きつけられる場面では確かにRESTは多少分が悪い。がXMLの冗長性を攻撃するのアプローチはどうかとおもう。ってのは、XMLが冗長なデータフォーマットであることは登場したときから最初からわかってることだから。パフォーマンスがクリティカルな局面であんな形式の電文を生で流すのはみんな「最初からありえない」前提だったわけでしょ？それを今更なにいってんのと。異文化（業種とか）間相互接続性（名前空間とか）が求められる世界ではXML、異文化相互接続性が不要なら人間にとってのそこそこの可読性を保てるJSON、で、パフォーマンスのため転送量減らしたければ、TransferEncoding: gzip。という形でRESTやっていれば、そこそこ困らない。（パレートの法則的に）
- HTTPの接続・切断のオーバーヘッドが気になるなら、KeepAliveすればいい。
- そもそもRPC vs Data という話で、あんまりRPCが必要な場面が個人的にはない。
- RPCが必要になる場面においても、CORBAやらなにやら、XMLより昔からある"効率的な"RPCと何が違うのかもよくわからない。
- ThriftやらProtocol Buffer実際やるとなったら、独自の定義体書くためにはそれを学習しなくてはならないし、細かい話、コンパイルするオペレーションをCIに組み込むにはどうすべきかなど、色々付随する作業が出てくる。その直観的コスト見積もりと、見返りである効果を考えたとき、今のところあまり魅力を感じない。
まあ、全く興味がないというと嘘になって、今、RubyとJavaの混在実装を扱ったりしていたりするので、実はふつうにRPCで実装するといいのかもしれない。けど、そもそもまだまだHTTPを使いこなせて（非同期IOとかWebSocketとか）いない今、そっちに時間投資するより、ちゃんとHTTPが使いこなせるようになりたいなと思う。
そんな感じ。まあ、FBやGoogle発だからブランド的にみんなが飛びついて普及するということなら、僕もいずれやるかもな。。っていうか、時間さえあれば、やってみたいとは、思う。
参考：
http://ohnaka.jp/blog/2011/08/493
http://blog.broomie.net/index.cgi?id=38
http://code.google.com/intl/ja/apis/protocolbuffers/
http://code.google.com/intl/ja-JP/apis/protocolbuffers/docs/faq.html
