Personally, I usually develop the Thrift services first and 'layer on' a JSON/HTTP interface to support integration with third party systems built by other developers who don't fancy Thrift.
So, technically; I deliver two APIs. And depending on the expertise of the integrator, they choose which one they want to speak to. On 27 January 2015 at 21:27, Gallagher Polyn <[email protected]> wrote: > I am unsure whether to specify a new service in terms of Thrift or > JSON/HTTP. > > I have read an elaboration by an original Thrift author, Mark Slee, of > relevant decision points on this matter,* including expected gain from the > advantages of strong typing, performance, serialization efficiency. > versioning support and server implementation, but I do not know how assess > those relative benefits for my new service, now. > > Allowing an even chance that the benefits of a Thrift service > implementation would later be judged superior to JSON/HTTP, is it still > preferable to specify the service (test specs) in terms of JSON/HTTP and > migrate later? Or, alternatively, might it be better to specify Thrift > services and 'layer on' a JSON/HTTP interface? > > * > http://www.quora.com/What-are-the-use-cases-for-Thrift-i-e-what-reasons-are-there-to-consider-using-Thrift-when-one-could-rely-on-JSON-and-standard-HTTP-requests > < > http://www.quora.com/What-are-the-use-cases-for-Thrift-i-e-what-reasons-are-there-to-consider-using-Thrift-when-one-could-rely-on-JSON-and-standard-HTTP-requests > > -- - Phillip. "Aoccdrnig to rscheearch at an Elingsh uinervtisy, it deosn't mttaer in waht oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht the frist and lsat ltteer are in the rghit pclae. The rset can be a toatl mses and you can sitll raed it wouthit a porbelm. Tihs is bcuseae we do not raed ervey lteter by it slef but the wrod as a wlohe and the biran fguiers it out aynawy."
