Using Thrift with Cappuccino
blog.parallel48.com
Using Thrift with Cappuccino
1–10 of 10 posts
Re: Using Thrift with Cappuccino
#2Anyone 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.
Re: Using Thrift with Cappuccino
#3Anyone 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.
Re: Using Thrift with Cappuccino
#4Anyone 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 questi…
Thanks for the reply. I'm not familiar with RPC, thus my newbie question. Thanks again.
Re: Using Thrift with Cappuccino
#5Anyone 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 questi…
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.)
Re: Using Thrift with Cappuccino
#6Earlier quoted context omitted.
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 questi…
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.)
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.
Re: Using Thrift with Cappuccino
#7Earlier quoted context omitted.
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 questi…
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.
Re: Using Thrift with Cappuccino
#8Earlier quoted context omitted.
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.)
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.
Re: Using Thrift with Cappuccino
#9Earlier quoted context omitted.
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.
Re: Using Thrift with Cappuccino
#10Anyone 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 questi…
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."