On Wed, 2018-07-25 at 21:53 +0200, MG wrote:
> I have no personal experience with either XML-RPC, SOAP or REST (DB 
> Developer, Web-GUI needs covered by Vaadin), but this guy expresses
> a 
> different (seemingly pragmatic) opinion (and he is using Groovy ;-)
> ):
> https://sites.google.com/a/athaydes.com/renato-athaydes/posts/theretu
> rnofrpc-orhowrestisnolongertheonlyrespectablesolutionforapis

He also does a lot of Ceylon work, but that is a for a different
thread.

> (Generally speaking, in modern software development especially the
> web 
> development domain to me seems to suffer from an overabundance of
> "this 
> is the /absolute /right way to do things !" - until a
> newer/hipper/... 
> (or simply different ?-) ) approach comes along the next year...; I
> mean 
> I am not saying there is no improvement in some areas, but it took
> the 
> web guys how many decades to rediscover configurable, encapsulated
> GUI 
> components as a general concept ?-) )

Everything in software development is tribal and fashion driven,
sometimes a fashion leads to a genuine intellectual improvement.

In a sense RPC over HTTP and RESTful Web Service are isomorphic.
However, RESTful Web Services is an HTTP solution to an HTTP transport
problem. Obviously it was new and shiny and therefore fashionable and
it caught on because of that and the microservices movement. However it
has a consistency that is appealing, and for me a genuine move forward.

Yes there is gRPC and protobufs, I simply forget to mention them in
trying to describe modern orthodoxy in Web Services – mostly I suspect
because I do not actually use it at all. Renato confirms in his article
that RESTful is the current orthodoxy.

It is interesting that Renato ignores SOAP and returns to XML-RPC.  As
for his code, HandlerAPI should be extracted so that both client and
server guarantee the same interface. Also interesting that the code
doesn't deal with XML, it is entirely hidden. So much so that JSON-RPC
is effectively a drop in replacement. This will raise the XML vs. JSON
argument which is another "safe technology" vs "cool kids" debate the
outcome of which hinges totally on whether there is a schema of the
packets.

So in the end Renato's code (amended) gives a Java solution, which
immediately means there is a Groovy solution, to the problem of
replacing the Perl, and there is no need for a special Groovy package.
  
-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to