A Critique of the Remote Procedure Call Paradigm (1988) [pdf]
cs.vu.nl
cs.vu.nl
At that point, this essay reads like EJB vs JS+REST. (at least if you translate the generalities to current common use cases)
Can you elaborate on the differences?
It is my understanding that REST is a specific, structured kind of RPC (equivalent, anyway) -- not a general RPC.
> Our criticism of RPC concerns: the advisability of its use as a general communica- tion model, for arbitrary applications. In many experimental systems to date, RPC has primarily been used for communication between clients and file servers. In this one res- tricted application, many of the problems we will point out below do not occur, or can be avoided by careful server design. It is our view that a general paradigm should not require programmers to restrict themselves to a subset of the chosen programming language or force them to adopt a certain programming style (e.g., do not use pointers in their full generality because RPC cannot handle them).
While Fielding lists some specific constraints on what REST is: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc... where he draws on various architectures laid out in chapter 3, Networ-based Architectural Styles (A chapter it seems no one ever reads...):
https://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch...
But is this a formal,normative spec or a dissertation ? because that's the main reason why nobody understand what REST is, because there is no paper about REST that is written in a formal way like spec should. If REST had clear and precise rules,then there would be a reference that acts as an authority.
I'm not sure why anyone would want anything more formal than the dissertation or mvc notes -- it's just some (good) ideas. Maybe the fact that they have their own acronym confuses people?
[Ed: I suppose WebDAV[2] could be considered a formalisation ... but again representional state transfer is derived from the unique demands/constraints of hypertext information systems; it's not a good fit for db systems. That doesn't change just because you deploy the front-end in a web browser...]
[1] http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
There lies the problem, some people still say that it something IS formal(thus they think they speak out of authority) Truth is,nobody has a fn clue what REST really is aside from its "creator", I still don't know myself and trust me , I read the original paper.
The problem is also that people oppose REST and XML-RPC when in fact XML-RPC IS a protocol,when REST is not. REST never ever said what a resource should look like, nor what a URL should look like. Strange for something that is supposed to replace SOAP ? (and i'm not a fan of SOAP )
The lack of formalism of REST has done a great deal of damage IMHO(One client per api...), so much than people are now reverting to SOAP like protocols ( like GraphQL , a unique client per language).
"Many different (often incompatible) technologies have been used to implement the concept." https://en.wikipedia.org/wiki/Remote_procedure_call
In contrast, when using a Webservice or REST API, nobody (I hope) thinks 'I don't need to worry about connection timeouts or the server being down or ...