> 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...):
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.
It's an architectural style. It's not something that's formal. Like MVC[1] or a style of constructing buildings.
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...]
> It's an architectural style. It's not something that's formal.
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).
The meaning of 'RPC' has changed a bit over the years. Central to the idea of 'RPC' as used here is that they calls should be indistinguishable from a local call. All 'remoteness' aspects were to abstracted away and the developer would not have to worry about them.
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 ...
