
Why REST Sucks - icedchai
http://vmrcre.org/web/scribe/home/-/blogs/why-rest-sucks
======
ppeetteerr
I'm not sure what upset this Mr. Graffittis so much, but he seems to be
excessively angry with HTTP verbs . Anyway, thousands of developers have found
ways around this problem. Here is one:

Most people use GET for retrieval, POST to change system state and DELETE to
delete an object. You might go crazy and experiment with PUT, or not, your
choice.

As a team, you can establish some easy rules too (e.g. is it books/1 or
books/book/1 to query a single book?).

Sure, REST is not going to answer every problem, but no standard ever does.
Standards are meant as guidelines (esp. those related to naming conventions
like REST). Have fun with it. Stop the hate.

~~~
philwelch
(disclaimer: TFA is dead for me right now so I might be speaking out of
context)

REST (like "object-oriented programming") is an ambiguous term that might
refer to a reasonable and usable subset of behavior, or it might refer to a
more extensive hypermedia-style design pattern.

REST, in the hypermedia sense, and in the sense of "the design principles
behind HTTP in the first place", is a good way for a server to expose data to
an intelligent human-guided client (i.e. a web browser). It doesn't do a lot
for the API case, but it does a little and there's enough tooling to get you
the rest of the way.

I usually don't even think of REST API's as RESTful. I think of them as RPCs
that exchange JSON, except you define the RPC endpoint as an HTTP verb/URL
pattern tuple, accept and treat as a contract the standards behind different
verbs, use response codes for out-of-band metadata, and piggyback on all the
tooling and infrastructure that people already built around serving HTTP to
web browsers in the first place. If you want to strongly type your RPC, you
can use OpenAPI. If you want to define your RPC ahead of time and then
generate server and/or client code from a definition, you can use Swagger
Codegen. There's enough adequate tooling that you don't necessarily need to
resort to an actual RPC protocol, but that doesn't mean your REST API actually
has to be RESTful in any meaningful way, or even that it should be.

~~~
weberc2
> is a good way for a server to expose data to an intelligent human-guided
> client (i.e. a web browser)

A web-browser doesn't have any concept of REST; it only provides a sandbox for
the client code which knows how to map paths to data (but pretty much never
does so by means of any sort of introspection). Note that this isn't
advocating against REST or in favor of RPC, just a neutral observation.

~~~
munk-a
Actually the original, core, really REST thing (that almost no one views as
REST anymore) is all about resource exposure, and a dumb browser doesn't know
how to interact with it but a REST aware generic browser could potentially
interact with RESTful endpoints without other assistance.

I'm specifically talking about the portion of rest that includes delivering
actions with noun results, i.e. "Here's you comment record, if you want to
edit it go to this URL, if you want to delete it here's a different one".

Also, I, personally, find that portion of REST to be silly. I like the
organizational hints and guidelines, but the resource discovery seems far too
pipe-dreamy to ever be built on a large scale.

~~~
dsego
I thought the general idea is to code the client against a well defined and
sanctioned media type. If the media type returns items and actions, a well
coded client should be able to handle it (whether it is to show it as GUI and
provide controls or do some automated response etc). The point of returning
actions is that URLs change, and must be able to change. Instead of following
HATEOAS guidelines, people hardcode routes and lament about how URLs should be
structured (flat vs nested, e.g. `/posts/1/commment/4` vs `/comments/4`) and
then they also have to be versioned etc. (`api/v2/posts`). Now that is silly.

~~~
philwelch
> If the media type returns items and actions, a well coded client should be
> able to handle it (whether it is to show it as GUI and provide controls or
> do some automated response etc).

In a web service context, is there a HATEOAS web client library that I can use
to make service calls without having to specify endpoints and request formats
ahead of time?

> Instead of following HATEOAS guidelines, people hardcode routes...and then
> they also have to be versioned etc. (`api/v2/posts`).

In the web service use case, it's considerably simpler to define and specify a
set number of endpoints ahead of time, define request and response formats,
document that specification in OpenAPI, and use versioning if the API itself
changes. This isn't RESTful. It's just RPC over HTTP. But it works and it's
not "silly".

------
psadauskas
Not to be too snarky, but this is just another "I did REST poorly and it
didn't work very well, so I guess REST sucks" post.

Most of the other gripes have been responded to, but I wanted to add a comment
about the "stateless" part: Its not that your _Application_ is stateless, its
the HTTP protocol itself that is. It is a contrast to other contemporary
protocols like FTP or SMTP, in which you establish a connection and then
perform "Commands", the order of which matters. In FTP, if you do:

    
    
        CONNECT ftp.example
        CD public
        GET myfile.jpg
    

The `CD` command in Line 2 changes the behavior of the `GET` in Line 3. This
different from HTTP in that each request is independent of any others. The
"state" is that the FTP server has to "remember" the current working directory
of each connected client. If there were need for a high-availability load-
balanced FTP provider that could support tens or hundreds of thousands of
simultaneous connections, it would be pretty difficult because you'd have to
maintain that state across all the servers. On the other hand, the stateless
nature of HTTP means we can have Proxies and Load Balancers and CDNs all over
the planet, and it mostly just works.

~~~
sopooneo
So are session cookies allowed?

------
restdoesnotsuck
The author's main beef in this article are the more exotic HTTP verbs. I don't
think that gets at the crux of why REST sucks for Web Services/APIs.

The core problem is that REST (which, recall is a description of the web
architecture) requires HATEOAS. JSON doesn't naturally implement a hypertext
in the way that HTML does and, further, the other end of a JSON call is almost
certainly _code_ , rather than a human, and thus isn't able to take advantage
of this feature anyway.

Here are a few articles on this general idea:

[http://intercoolerjs.org/2016/01/18/rescuing-
rest.html](http://intercoolerjs.org/2016/01/18/rescuing-rest.html)

[http://intercoolerjs.org/2016/05/08/hatoeas-is-for-
humans.ht...](http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html)

~~~
droussel
I've designed and implemented a few REST api over the years that both made use
of json for resource representations and also used hyperlinks. You do need to
create your own media types and document them properly though, but media types
and relations are at the core of any good REST APIs.

------
interesthrow2
It sucks because it's not a spec, that's all. HTTP is, GraphQL is. When
implementing GraphQL either you follow the spec or it is not GraphQL. Same for
HTTP. An vague idea shouldn't be the basis for architectural choices and I'm
glad REST and its legacy are now criticized and contested.

~~~
paulddraper
I assume your criticism applies to OO? Or functional programming? Or event
sourcing? Or any number of programming concepts without a "standard"?

~~~
interesthrow2
> I assume your criticism applies to OO? Or functional programming? Or event
> sourcing? Or any number of programming concepts without a "standard"?

Don't assume anything, I never talked about OO, or functional programming, or
event sourcing or any number of programming concepts without a "standard".
Don't make up things in an attempt to further whatever point you are trying to
make here. I never talked about those things and don't care about them.

------
madmaniak
Article doesn't loads for me. Whatever is said, the answer is simple. REST was
meant to be used by other applications in a not yet known way, and many where
claiming REST is a "best practice" for API of YOUR single page application. It
led to doing the same thing in a huge scope twice - selecting, modelling, and
preparing for view of data, maybe even more. So we didn't use the context of
the query which already shapes the data. GraphQL does. But GraphQL sucks in
other way - as it adds unnecessary querying language (which already exists on
the backend and it's for sure more powerful), and it makes a query on the
frontend which is a security issue (which you can limit on the backend, but
it's just a consequence of this mistake and still leaky).

------
amaccuish
Wayback link if it's not loading for anyone else:
[https://web.archive.org/web/20181217220412/vmrcre.org/web/sc...](https://web.archive.org/web/20181217220412/vmrcre.org/web/scribe/home/-/blogs/why-
rest-sucks)

------
thinkingkong
I'd love to hear from the folks at Slack to see how their initial API design
decisions scaled. Their model is pretty clean and I really like the look and
feel of it, aesthetically at least it's RPC-ish.

Part of the challenge when people have arguments like this is that they aren't
experiencing the trade-offs in the other directions they'd like to go, so it
would be great to hear the concerns about an RPC alternative which restricts
the HTTP verbs to GET & POST.

------
Arzh
`We went from Procedural Programming, to Object Oriented Programming, to
Functional Programming`

I mean, it's not really a progression; even inside of OO and Procedural there
are a lot of differences and it's not like any of those are better than the
other, they just allow you to write code that does the same thing in different
ways.

------
crazygringo
This seems like an... unnecessarily _angry_... bit of a rant.

BUT, I tend to agree. Just use GET for all requests that don't change things,
and POST for those that do (important so spiders and pre-caching don't
inadvertently take actions), and put everything else (including what the real
verb is) in the URL or parameters.

The idea of trying to shoehorn your logic into additional PUT and DELETE verbs
is unnecessary and makes it harder to use/support (e.g. HTTP forms don't
support those verbs).

And... that's it. Fortunately I've never had to work with a die-hard REST
evangelist, so maybe I've never had to feel the anger or frustration this post
must be coming from...

------
leeoniya
looks like the site's being hugged to death.

nevertheless, i've had many annoying situations where i want to GET a specific
list of ids, eg. /orders?ids=1235678,abcdefg and quickly run into the 2048
char limit, forcing me to design the API as a POST in all cases. combine that
with additional sorting, grouping and filtering params and you're stuck.

the fact that GET is conflated with the url and has no body to pass params in
is very limiting. at that point, HTTP verbs become mostly pointless.

~~~
tuespetre
When do you need to get a list like that where they couldn’t be collectively
addressed by some other resource identifier? If we treat our “REST APIs” as
generic database interfaces instead of equipping them with more semantics, of
course we hit that wall.

~~~
leeoniya
if a user selects a bunch of options and records in the interface and then
wants to pull an aggregate report on specific items which would translate into
some _AND id IN (...)_.

what if you need to delete a bunch of specific records in a single HTTP
request with REST? you're fucked. DELETE is designed to deal with one record
at a time [1]. sure, DELETE _could_ have a body, but the recommendation is to
ignore it [2].

to operate on multiple specific records, you're stuck doing at least 2
requests. a POST that asks the server to create some temporary "collection"
record. and then use the new URI of that collection to perform more
operations. why do all this overhead when you can just do the delete operation
with a POST request and a body filled with record ids?

i could continue, but it should be obvious that REST was designed with the
server as the center of the universe. when trying to shoehorn this worldview
into modern fat clients and high-perf SPAs, it very quickly falls down.

[1]
[https://www.restapitutorial.com/lessons/httpmethods.html#del...](https://www.restapitutorial.com/lessons/httpmethods.html#delete)

[2] [https://stackoverflow.com/questions/299628/is-an-entity-
body...](https://stackoverflow.com/questions/299628/is-an-entity-body-allowed-
for-an-http-delete-request)

~~~
dsego
I don't think POST-ing to a /delete-records resource goes against REST, the
original one, not the “common” one.

~~~
sopooneo
That's an interesting idea I hadn't ever thought of. But would such an
endpoint return anything meaningful on a GET request? Would it return a list
of all deleted records?

------
crooked-v
> Well, it means that I can easily program all my web services to accept both
> GET and POST (normally without changing any of my server side code, to
> seamlessly accept either)

...unless you've got more params than can fit into the de facto URL length
limits of browsers (~2K characters for Internet Explorer), in which case
you're stuck with POST.

~~~
pdonis
Or if the request has side effects, which GET requests are not supposed to per
the HTTP RFCs.

~~~
ArchTypical
RFCs are often useful guidelines, but don't get too hung up on them. There are
always side effects. eg resource usage, interaction effects (cache priming),
etc.

[Edit:] > The point is that GET is not supposed to change the information
stored on the server side.

The RFCs for HTTP USAGE are guidelines that are less about utility and more of
an interoperability dream that was never realized. There's nothing sancrosanct
about them. There have been DECADES of usage contrary (eg medical, gamedev,
advertising, ERP, etc). At some point people realize it's bikeshedding issue
that's more trouble than it's worth.

~~~
pdonis
_> There are always side effects. eg resource usage, interaction effects
(cache priming), etc._

"Side effects" probably isn't the best term for what I meant. The point is
that GET is not supposed to change the information stored on the server side.

------
teliskr
I'm not trying to go out of my way to be snarky... BUT I find it funny that
someone writing about why a technology sucks; can't manage to keep their blog
online.

REST is simple, simple is good. It's not perfect for everything, but it has
served my purposes well for many years.

------
revskill
REST sucks because there're many ways to do something. Consider RPC, if you
want to do something, you make an endpoint /doSomething, that's all, no need
to mess around with combination of [http methods][noun(s)]([business method])

------
maxxxxx
I tend to agree. I have worked now with a few REST APIs and it seems none of
them implemented REST well. Just adding verbs like "delete" or "get" to the
URL feels better to me compared to using HTTP verbs.

~~~
batoure
I think this is a version of the right answer. I would love to see someone do
a teardown of all of the Best in class REST interfaces. Because the reality is
some of the systems that get pointed to as most robust and we'll designed
generally all contain a place where they have heavily skewed from the
standard.

All that being said I think REST is an architectural pattern that can bring
some order to the chaos. And I have seen thought experiments experiments that
embrace it's constraints bring significant performance enhancements to many a
system.

~~~
munk-a
I've worked with systems that use RESTish patterns purely for request pattern
conformity, eschewing any of the auto-discovery portions. I've found that
reliance on verbs for noun modification with some separate action verbs builds
a system that is very clean to interact with but... it's all in the details,
there are plenty of terrible RESTish systems out there and there are some
wonderful systems built on alternate patterns (like XML RPC).

I think the one thing RESTish design can bring is a simplification to the
communication layer, but if you're interacting with it through HTML forms then
you'll need hacks to get it working in the first place (many HTTP verbs are
not supported as methods by most browsers).

Basically, it's an additional tool with some value for organization, if you
use it zealously you can waste years of labour building a perfectly RESTful
system. Do what works for you.

------
tuespetre
Obligatory link to Fielding’s nearly decade-old blog post, “It is okay to use
POST”:

[https://roy.gbiv.com/untangled/2009/it-is-okay-to-use-
post](https://roy.gbiv.com/untangled/2009/it-is-okay-to-use-post)

The ‘recall’ and ‘sendpromotion’ ‘actions’ are still resources: ‘the resource
that does a recall’ and ‘the resource that sends a promotion.’ You don’t ‘GET’
them or ‘DELETE’ them or ‘PUT’ something in their place. You just send a
request that triggers those resources to do their thing: ‘POST’. It’s not CRUD
and it’s 100% valid.

------
paulddraper
Sigh. Site down.

Archive link
[https://web.archive.org/web/20181028175819/http://vmrcre.org...](https://web.archive.org/web/20181028175819/http://vmrcre.org/web/scribe/home/-/blogs/why-
rest-sucks)

In 2018 with gigs of RAM, super fast internet, and billions of Hertz, it seems
like more the web should be "web scale" than it is.

------
k__
Using GraphQL somehow lead me to not worrying about all that low level REST
stuff anymore.

I define my schema, sprinkle some directives and push it to AppSync.

------
teen
RPC is the way to live

~~~
crescentfresh
Does this mean POST for every request?

~~~
philwelch
Not for me; I'm willing to use GET for an RPC that's more GET-ey and DELETE
for an RPC that's more DELETE-ey.

------
daxfohl
It becomes more clear to me in the context of api versioning. You rev the
action, not the data. REST versioning makes it look like like you're
versioning the data. Sure you can explain it away, but it smells not right.

------
daxfohl
Main problem is that most of the frameworks out there are REST / noun based,
because it's easier to scaffold. Are there any that are more rpc/post/verb
based out of the box?

~~~
philwelch
Basically any HTTP microframework that has a minimum of ceremony between
"declare HTTP URL endpoint" and "write function that handles requests to that
endpoint". Flask, Sinatra, anything like that.

Or, you could use swagger-codegen and generate your service from a handwritten
OpenAPI spec.

~~~
daxfohl
Basically agree, but was thinking more about something with a scaffold that
specifically guides users _toward_ a separation of actions and nouns, not just
an indifference.

~~~
philwelch
swagger-codegen kind of does that, with the tradeoff of making you define your
API contract ahead of time.

------
droussel
I hate it when people criticizes something they do not understand properly in
the first place... Is it so hard to read Roy's thesis and do some proper
research?

------
cztomsik
the worst thing about REST is that nobody agrees on what it is...

otherwise it's pretty fine, you just need to find a good server-side framework
with proper tooling (springfox for java, nest.js for node) so that you don't
need to write documentation (and test-console) yourself

graphql is great if all what you want to do is to publish some data but once
you need more updates or predictable performance, it's not so easy anymore,
and this is not just my opinion

~~~
dsego
Nobody except Roy Fielding.

------
gweinberg
"You know they try to eat non-mushy peas balanced on the backs of their
forks!" Is that true? Why would anyone do that?

