Thanks Phillip and Randy for your responses. I've added a couple of brief comments/questions to digested versions, farther below.
I had written (condensed here): 'I am unsure whether to specify a new service in terms of Thrift or JSON/HTTP [...] 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?' ..and Phillip responded: "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*.*" Phillip, that sounds time-consuming, unless the HTTP/JSON layering is kind of boilerplate. Can you refer me to any references that describe something like your steps? Meanwhile, Randy wrote (edited): 1. ROA and REST: great for internet facing broadly distributed, read mostly interfaces 2. Hand coded IPC: great for extreme scenarios (brittle, not needed by most and hard to justify) 3. Thrift: great for everything else (which I find is a lot), in particular SOA ...which he had elaborated (thanks!)... [1] one of the key factors in thinking about Thrift and HTTP/JSON > is whether you are going to go with a Resource Oriented Architecture > (ROA) or a Service Oriented Architecture (SOA). > > [1] I have found the architecture of the web... easier to leverage with REST and > ROA....The web is ROA and the Internet is designed to support this at > every level. > Great, helpful! > [3] Apache Thrift is much faster in cases where dynamic operations are > involved, that is to say, where the client actually needs to talk to > the server, not an intermediary. Randy, can you elaborate on why a web service design would call for an intermediary, unless it were post hoc? > [3] Thrift fits well as a general purpose > solution on the backend and in some cases even the front end. > Underrated, I think, is also the cross language serialization features > of Apache Thrift. For example we use Thrift to serialize messages > (Thrift structs), in particular for transport over > RabbitMQ/Apollo/ZeroMQ etc. OK, this guidance sounds relevant when a service is known to be backend. > [1,3] Also keep in mind that in regards to many workflows, folks have > been trying to get out of the HTTP channel for quite a while. > WebSocket was created to allow us to eliminate the overhead of HTTP in > the browser. Thrift is happy to communicate over HTTP, WebSocket or a > string an two tin cans. > OK, this guidance sounds relevant when a front-end service use case might call for WebSockets For extreme IPC (Inter Process Communications) speed I have found > that just grabbing bits out of RAM and sending them is hard to beat. > No serialization overhead, no mem copies, etc....The fact that you can > evolve Thrift (and REST) > interfaces without breaking existing code it a huge feature to give > up, easily justifying the serialization overhead of Thrift in most > settings. > > In this bit, Randy, are you expressing a connection between 'extreme IPC' and 'the fact that you can evolve Thrift interfaces'? If so, I don't understand, but would like to. Thanks again! G
