
RESTful APIs, the big lie - ricny046
http://mmikowski.github.io/the_lie/
======
toyg
What the author ends up proposing, as usual, is basically RPC-over-JSON.
Replace JSON with XML and RPC with SOAP, and you get the sort of monster-
construct the REST movement was born to fight.

This particular sentence says it all: "the message content should be
independent of the transmission channel." That's the RPC dream: no matter what
the pipe is, I'm sending you stuff to do. The problem, of course, is that in
practice the transmission channel is _never_ neutral: for example, HTTP and
RMI are very different beasts, and in practice applications built on top of
either one will end up relying on this or that assumption about the protocol,
no matter how hard you try to standardize them. Same for any transmission
protocol out there, really. You just have to decide when to stop trying to
abstract everything away and do your work, because each additional abstraction
is inevitably leaky. In this sense, REST basically tells you to stop right
there and get to work. REST is not a "transmission channel", it's an
application design philosophy for applications built on HTTP. End of.

Pretty much all his other objections can be fixed by using proper response
codes and _intelligent_ payloads that _do not include verbs_. The only verbs
you need are in HTTP already - GET, POST and DELETE will cover 99% of your
requirements. They make your API substantially _predictable_ and _robust_. The
minute you start putting verbs in payloads, you're doing RPC and you might as
well use CORBA. If this is what you want, go ahead and do it, but don't say
it's REST's fault if you don't understand what REST is.

~~~
dozzie
> [...] GET, POST and DELETE will cover 99% of your requirements.

Hardly. There's no search in these. You end up putting your query either to
URL, which is hideous, or to request body, which is awful.

The only HTTP verb that can sensibly carry anything beside "create",
"destroy", and "retrieve" commands is POST. This equals to operation
"manipulate". And guess what? Plenty of remote interfaces use _at the same
time_ many operations that can be called "manipulate". Sticking to merely HTTP
verbs is way, way too constraining.

~~~
toyg
_> Hardly. There's no search in these. You end up putting your query either to
URL, which is hideous, or to request body, which is awful._

We'll just have to disagree there.

In any case, if you find REST restrictive, fine, go ahead and do your RPC.
Just don't try to tell me that it's anything other than RPC, with all the
problems and warts we all know.

The value in REST is exactly that it forces you to simplify your interface
down to basic verbs that everyone can understand and work with; if you can't
do that, if additional complexity is unavoidable, then REST is not for you and
you should be aware that your application is now officially _complex_ , maybe
too complex to be a public API.

From that point of view, something like SOAP is a perfectly respectable
protocol and you should use that instead.

~~~
dozzie
> [...] fine, go ahead and do your RPC. Just don't try to tell me that it's
> anything other than RPC, with all the problems and warts we all know.

Why the heck do you think that "lol, you use RPC" would be an insult? Because
you clearly send this message with your tone.

I put RPC wherever I need an operation(s) to be called remotely. And yes, I do
use dedicated RPC protocols (namely, XML-RPC, for popularity of its clients).
I rarely create things that boil down to being a CRUD database interface, so I
find REST very limiting.

> From that point of view, something like SOAP is a perfectly respectable
> protocol and you should use that instead.

Apparently you haven't worked with SOAP. No, it's not respectable. It's
overcomplicated itself, it uses overcomplicated format (XML with namespaces),
and its tooling is overcomplicated, too (e.g. try to control how WSDL looks
like, so you can swap implementation languages; or try to create WSDL
beforehand, and then implement its backend in a language of your choice).

Really, in HTTP-based remote call protocols (this includes REST!), Microsoft
hit the spot twenty years ago with XML-RPC. The only two things missing are
null/None/undef encoding and named procedure arguments.

~~~
toyg
_> Microsoft hit the spot twenty years ago with XML-RPC._

Well then, why are we even arguing about this? You like pasta, I like pizza,
and never the twain shall meet. REST was born out of rejection for XML-RPC
(and SOAP, which was its logical evolution once The Enterprise got involved).

If you like XML-RPC, by all means keep using it. I just don't see the point in
advocating (as TFA does) that people should abandon working on REST
implementations in order to embrace what is basically JSON-RPC, i.e. a
completely different thing from a philosophical and design perspective.

(I've ignored the ad-hominems and bad guesses on my work history. Can we keep
it civil?)

~~~
coldtea
> _REST was born out of rejection for XML-RPC (and SOAP, which was its logical
> evolution once The Enterprise got involved)._

Not even remotely true. REST was a re-invention of XML-RPC wheel -- for the
web and using baroque HTTP conventions that were meant for documents and
hyperlinks.

XML-RPC was never rejected because it never caught much on in the first place.
On the enterprise they pushed for SOAP at the same time, and on the web it
wasn't yet a period were anybody really did rpc (plain AJAX, REST or any other
kind).

In terms of simplicity it goes like: XML-RPC -> REST -> abyss -> SOAP, with
XML-RPC and REST both on the far "simpler" end of the scale compared to SOAP.

~~~
dragonwriter
> Not even remotely true. REST was a re-invention of XML-RPC wheel -- for the
> web and using baroque HTTP conventions that were meant for documents and
> hyperlinks.

Not even remotely true. REST is an architectural style inspired by the then-
existing web, describing an idealized structure based on it, and developed in
parallel with and guiding HTTP/1.1. It does not mandate HTTP conventions,
though HTTP is itself an _example_ of the style.

REST only involves HTTP conventions to the extent that one decides to use it
over HTTP, and only because HTTP involves (obviously) HTTP conventions.

~~~
coldtea
Not even remotely true.

REST is what it is in practice, not what some guy originally proposed as REST,
in the same way modern words are not their etymology in Latin or Greek.

And in practice it's a re-invention of RPC, similar to XML-RPC, over HTTP and
JSON, but with less rigor.

Kind of like any big C program has an ad-hoc implementation of half of Common
Lisp thing.

> _REST only involves HTTP conventions to the extent that one decides to use
> it over HTTP, and only because HTTP involves (obviously) HTTP conventions._

Ok, then you should have no issue with not using HTTP conventions and just use
HTTP for transport.

------
antimora
JSON-pure API? Do you mean SOAP but with JSON instead of XML?

~~~
mjevans
About all I gleaned from reading it was a big list of reasons why 'RESTful' is
bad, and that the main solution was to use HTTP(s) as purely a transport
layer.

What, exactly the 'solution' will look like depends on future posts... however
[https://xkcd.com/927/](https://xkcd.com/927/) (Standards) comes to mind.

