
A Critique of the Remote Procedure Call Paradigm (1988) [pdf] - vezzy-fnord
https://www.cs.vu.nl/~ast/publications/euteco-1988.pdf
======
DenisM
Related critique of RPC: [http://erlang.org/pipermail/erlang-
questions/2008-May/035209...](http://erlang.org/pipermail/erlang-
questions/2008-May/035209.html)

------
zkhalique
So I think this is solved with also adding server push to the model. Like
registering callbacks.

~~~
Roboprog
Looking forward to a few years down the road when enough IE versions die to
start using WebSockets for this :-)

At that point, this essay reads like EJB vs JS+REST. (at least if you
translate the generalities to current common use cases)

------
ExpiredLink
A classic. Interestingly, RPC-like solutions like SOAP and REST thrive
nowadays.

~~~
talideon
REST isn't RPC-like, though it's not uncommon for RPC-like APIs done with HTTP
to be incorrectly described as 'REST APIs'.

~~~
beagle3
> REST isn't RPC-like

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.

~~~
e12e
From the article:

> 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...](https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm)
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...](https://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_styles.htm)

~~~
aikah
> 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.

~~~
e12e
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...]

[1] [http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-
index.html](http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html)

[2] [http://www.webdav.org/specs/](http://www.webdav.org/specs/)

~~~
aikah
> 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).

~~~
e12e
Um, there are _many_ RPC protocols? Remote Procedure Call isn't _one_ thing.
"RPC" can mean a certain implementation of RPC, or it can mean "just" RPC.

"Many different (often incompatible) technologies have been used to implement
the concept."
[https://en.wikipedia.org/wiki/Remote_procedure_call](https://en.wikipedia.org/wiki/Remote_procedure_call)

