

Ask HN: REST or RPC? - aashishkoirala

I know that REST is one of the most misunderstood and abused architectural styles today and most of the population that throws the word around doesn&#x27;t actually know what they&#x27;re talking about. I&#x27;ve been trying to wrap my head around <i>actual</i> REST (as in Richardson&#x27;s Maturity Model Level 3) and trying to contrast it with RPC. So far, I have to admit, it&#x27;s not doing much for me. It may be that the RPC style of doing things is so engrained in me - but the RPC way just seems more natural and easier to me.<p>I&#x27;d be interested to hear from people who&#x27;ve done both RPC (I come from the .NET space, so my flavor of RPC is mostly WCF) and REST - in what situations would you pick REST over RPC?
======
rpedela
REST is completely fine if you are providing an HTTP interface to a key/value
store. If the API performs complex logic then RPC is much better. You will
likely rip out all your hair trying to force complex logic into a REST API.
SQL is an example of an RPC API that does not fit REST at all. In a single
query, you can read and write data or call a custom function which could
literally do anything. Except for basic CRUD, it would be nearly impossible to
make SQL a REST API.

The other thing to keep in mind is that REST has become a marketing term.
Business people do not know what REST is, but they do know that if they see it
then it is usually a good thing. Don't know if that matters for you.

~~~
aashishkoirala
That is exactly the impression I got, and I guess it is true - it has become a
marketing term - and joined the likes of SOA and Agile - yet more in a list of
terms people who have no idea what they're talking about like to abuse.

------
platinumdragon
I'm pretty surprised to read such uninformed comments on hacker news, but then
I'm relatively new the community.

Yes, RPC is better suited for complex abstract actions where you don't have a
resource as a context, whereas REST is better suited for resource-based access
and actions. Both should have a place in your toolbox, and to say that one is
superior to the other is simply trolling for a religious war.

REST is not relegated to CRUD, and is being grossly misrepresented when it is
said to. SQL is a scripting language, not a RPC or REST API. If you can make
SQL into a RPC, I'd love to see it. It must be absolutely nasty.

RPC is great for situations where you don't necessarily need an answer, or the
answer is so abstract that it doesn't really relate to a specific resource.
The great thing about RPC is you usually have something like a WSDL that many
tools can use to generate your client code for you. It makes it very easy to
implement into your client project, but can be very brittle, as any changes to
the WSDL will break the client.

REST is great for when your actions revolve around resources, whether they be
actions or access. Not everything needs to be relegated to the URL. You can
post or put just about anything in the body, including SQL if you were so
inclined (please don't ever do something like that). The thing about this is
you're using the resource in the URL as context, so it's a different way of
modeling your API. Though there is WADL and a couple of other standards for
describing a RESTful service, none of them are well accepted and there is poor
tool support for generating client code for you. This is a disadvantage in
that it forces you to roll your own code (which probably averages about 5
lines per call), but is an advantage in that you can easily follow a "tolerant
reader" methodology which makes your client highly resistant to API breakage.

If you're smart, you'll use HATEOAS in your responses. It may not be used by
all clients, it's up to them, but it does allow flexibility if they do use it.
We've had great success with it at the Fortune 100 company I work for.

I agree that many people use REST as a marketing term and don't fully
understand it. Those who do though are using it successfully and enjoy when
the opportunity to use it for their project. The important thing is to
remember that both are important and not try to fit one into a hole that calls
for the other.

------
argonaut
It bears noting that when people talk about REST(ful) APIs, they are not
actually talking about strictly 100% pure REST. Some parts of the original
REST spec are impractical in practice (HATEOAS, anyone?) and are never used.

~~~
dragonwriter
HATEOAS works pretty well for the web, so I don't know that I'd say its never
used or impractical. Most people who talk about RESTful API's seem to use it
as a term for RPC-over-HTTP without the overhead of SOAP, rather than to
meaning anything with even a passing resemblance to what was described in
Fielding's thesis.

~~~
argonaut
It's never used in RESTful APIs, which is what I mean.

~~~
dragonwriter
Almost none of REST is used in most "RESTful" APIs except incidentally,
because "RESTful" APIs are usually simple RPC-over-HTTP, and have nothing to
do with REST.

OTOH, there are RESTful APIs that actually try to use REST, including HATEOAS,
such as PayPal's [1].

[1]
[https://developer.paypal.com/docs/integration/direct/paypal-...](https://developer.paypal.com/docs/integration/direct/paypal-
rest-payment-hateoas-links/)

~~~
aashishkoirala
Thanks for the link to PayPal's API. I would be curious to know if doing pure
HATEOAS like that has reaped any specific benefits for them.

