|Re: [ecf-dev] interesting article against ReST|
On 7/30/2015 10:25 AM, Wim Jongman wrote:
Yes that is interesting.
For my $0.03: I've never believed in a 'one-size fit all' approach to distribution systems and rpc. As stated in the article, it is perhaps impossible to have a single transport/distribution system meet *all* requirements, whether functional (contract) or non-functional (e.g. performance and security).
That is one reason I like ECF's approach of implementing a standardized RPC (aka OSGi Remote Services/RSA), via open APIs that allow multiple distribution systems to be easily used, extended, or replaced entirely...at the level of each individual service. This also allows the option of doing design, development, testing of remote services on one transport, and using some other transport/distribution system for deployment. I believe this can make integration much easier and flexible, while maintaining clear, versionable contracts (the service API and types) between service providers and service consumers.
Of course, particularly given their ubiquity RESTful approaches are ideal for many situations , so I guess I disagree with the author somewhat, but my belief is he's trying to make the 'one size doesn't fit all' argument as strongly as possible.
Actually, I feel that he didn't mention a couple of other areas of potential weakness for RESTful approaches...e.g. the dynamics support inherent in networked/unreliable service (such dynamics are in OSGi remote services), and he does mention versioning (which is also very nicely handled by OSGi remote services/RSA) in the 'Backward Compatibility' section. Versioning is something that I believe justifies Remote Services over REST , by itself.
Like the author, it's also my view that Remote Services are not the 'whole story' of inter-process communication. There's also async one-way, queue, multipoint/process group models, events, etc....e.g. . In any event :-), indeed an interesting article, thanks.