Use Apache Thrift to publish web service API
Jason Robinson
Public
Seen by 28
Poll Created Tue 11 Sep 2012 8:50AM
Use Apache Thrift to publish web service API Closed Fri 14 Sep 2012 8:43AM
"The Apache Thrift software framework, for scalable cross-language services development, combines a software stack with a code generation engine to build services that work efficiently and seamlessly between C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, OCaml and Delphi and other languages."
Recently came across this framework. Sounds like a really good way of generalizing the data exchange of applications via web services.
I propose when the API code discussion and design goes forward that Apache Thrift be kept seriously in mind as a framework to publish the web services out. This would make it much easier for application developers to build on the web services.
Results
| Results | Option | % of points | Voters | |
|---|---|---|---|---|
|
|
Agree | 0.0% | 0 | |
| Abstain | 40.0% | 2 |
|
|
| Disagree | 60.0% | 3 |
|
|
| Block | 0.0% | 0 | ||
| Undecided | 0% | 47 |
|
5 of 52 people have participated (9%)
Florian Staudacher
Tue 11 Sep 2012 3:43PM
seems like bringing a gun to a knife fight ;)
(just too much)
Steven Hancock
Wed 12 Sep 2012 5:17AM
Thrift is overkill, we just need a good JSON API with OAuth like Facebook, Twitter and GitHub.
SleepyDaddySoftware
Thu 13 Sep 2012 11:05PM
I'm going to be writing mobile clients as soon as an API is out. I do NOT want to have to figure out how to properly parse some verbose payload format. Just use json or XML, standard formats (atom, activitystream, etc...)
Jason Robinson Tue 11 Sep 2012 10:56AM
I don't have such a comprehensive view of the D* core code so it could be this doesn't make sense :)
Florian Staudacher Tue 11 Sep 2012 11:51AM
ok, from the looks of it, this is just a middleware that makes network communication transparent to the used data objects (kinda like ZeroC Ice or Google protobuf) ?
Jason Robinson Tue 11 Sep 2012 1:56PM
Florian, yes.
Florian Staudacher Tue 11 Sep 2012 3:42PM
If we'd build the API on thrift, every client would have to use our thrift-generated "lib" to communicate with it. I don't think we should even make the API so complicated as to require passing whole objects. The whole idea should be "as easy as possible".
Therefore introducing an abstraction layer seems like overkill. We should rather use existing methods like JSON and just simple HTTP POST/GET with oAuth...
Sean Tilley Tue 11 Sep 2012 8:40PM
Honestly, from what I can tell, our currently internal API just leverages Backbone.js. Wouldn't it just be easier to leverage that instead?
Jonne Haß · Tue 11 Sep 2012 9:13AM
This doesn't looks to easy integrated into OAuth at all. The hard part about the API is the custom OAuth flow we need (tent.io is going roughly the same way, maybe we can join for a lib), not the boilerplate, that is just a bit annoying.
Also I don't feel good about requiring the clients to have a specific software dependency (or document their protocol), what if one wants to build a client where's not available? Thrift looks great if you build both, client and server, but for our use case the savings might not outweigh the troubles it introduces.