Note: This discussion was imported from Loomio. Click here to view the original discussion.
Proposal: Use Apache Thrift to publish web service API
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.
- Yes: 0
- Abstain: 2
- No: 3
- Block: 0
Note: This proposal was imported from Loomio. Vote details, some comments and metadata were not imported. Click here to view the proposal with all details on Loomio.
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.
I don’t have such a comprehensive view of the D* core code so it could be this doesn’t make sense
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) ?
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…
Honestly, from what I can tell, our currently internal API just leverages Backbone.js. Wouldn’t it just be easier to leverage that instead?
Closing this as it was probably not as good as an idea as it seemed at the time. Should not have even proposed before thinking more about it, sorry gets his coat
Not a problem, Jason. At the very least, bringing up this idea led to some useful and interesting insights.