Using Thrift with Cappuccino | Hacker News Reader

Using Thrift with Cappuccino

blog.parallel48.com

25 pointsfpotter9 comments

Anyone care to explain what problem thrift solves. I sort of understand what it does but I can't really get where/why one would have to use it?

Thanks.

Thrift solves the same problem as pretty much any other remote procedure call (RPC) system. Among RPC systems, I'd say it's notable because it works easily with over a dozen different languages and is fairly transport agnostic (you could use it over TCP, HTTP, or whatever else you like). Some care is also taken to be byte efficient, so it's not as heavy as something XML-based like SOAP or XML-RPC.

But, is your question more why would you use something like Thrift over just plain REST with JSON? You could accomplish the same things with REST/JSON, but in a lot of languages, I think the REST route involves writing more code. Instead of just making a method call and having it all happen for you, you encode some structure to JSON, do some HTTP operation, decode. I like it when that's hidden from me.

Good post. Another focus of Thrift (and Google's "protocol buffers", its inspiration) is that modifying your RPCs in a forward compatible way should be easy and have well defined semantics. (Thus the need for a tagged-base stream.) And, old clients should continue to handle new data in an acceptable manner. (i.e. They should not discard new fields that they do not know about.)

IMO Thrift/protobufs also add a lot of value having a single file to describe the shared protocol, compared to e.g. JSON, where it tends to be more ad-hoc or "look at example results for reference."

What I've never understood or appreciated about REST interfaces is that everywhere else in programming, the function / parameter / return paradigm is how we do things. Why do services over the web need to be different? It seems clear to me that something like RPC is what I want. (Which is not to say the particulars of XML-RPC or especially its implementations are anywhere close to ideal.)

I agree, and it's certainly what I want as a developer.

But, if I was building a web service that was supposed to be widely used (maybe some like the Yelp or Facebook API), I might think about REST. You know it's going to be immediately understood by everyone, and you don't have to worry about weird dependencies. And, being able to show examples using just curl is kind of nice, too.

Well, keep in mind that when most people say "REST" what they mean is a web call that sends or receives JSON/XML.

Personally, I've found that there are some things that fit really well into a fully REST-ful design, but sometimes you just want to deal with JSON over http, and that's okay too.

I think I'm guilty of that. :-)

It took me a really long time to figure out what RESTful design meant. As best I can tell, it's CRUD mapped onto the HTTP verbs.

As long as you don't call it REST, then the purists shouldn't have a problem with it. I'm not a purist myself, I'm more about getting things done, and sometimes a useful API just doesn't map cleanly onto REST.

Thanks for the reply. I'm not familiar with RPC, thus my newbie question. Thanks again.

Reply on news.ycombinator.com