I was sold on Thrift but I think the popularity of REST made people take some weird decisions.
Internal services talking to each other using REST seemed like a bit too much, a place, where I though services like Thrift would have worked so well.
I was sold on Thrift but I think the popularity of REST made people take some weird decisions.
Internal services talking to each other using REST seemed like a bit too much, a place, where I though services like Thrift would have worked so well.
We personally decided to stick with HTTP (even though Thrift would be "superior") since tools are numerous and simple. It's hard to beat curl and a browser. We also found that services end up used in ways that are hard to predict, especially in bash-written tools and the like. Thrift is a barrier to entry.
Additionally, you could do HTTP+Thrift. It's possible, it works, but you lose some of the overhead benefits of Thrift at that point (IMO). In my experience, fulfilling a Thrift request with a Thrift server has tighter latencies at much lower CPU usage for similar request loads.
I like working HTTP but certainly tools like thrift have there. LinkedIn is all about http://rest.li/ for our services though I've been working with DropWizard on a side project and really love it.