
Ask HN: Why REST? - kizer
RESTful APIs are dominant currently. However, it seems to me that elements of the REST &quot;style&quot; are constricting for no reason.<p>I see how conforming to the original intention of the HTTP methods may be elegant or in some way natural, but I can&#x27;t summon any kind of compelling justification for a restriction to only GET, PUT, POST, DELETE - aside from their analogy with CRUD I guess. Using GET forces parameters to be placed in the URL; wouldn&#x27;t it be nice to deal with only POST requests with JSON bodies? APIs could still be CRUD-like if they only used the POST method.<p>I know that the original conception of HTTP was centered around resources and their relationships, transfer, etc. - but the most natural kind of interface, to me, is one that simply exposes functions&#x2F;methods - like RPC. Web APIs are almost always accessed programmatically anyway.<p>Could anyone please enlighten me?
======
x0hm
REST isn't a standard protocol. It exists and is used by convention.

Throw a rock and you'll hit a developer who understands REST a little
differently.

While there are technically "more correct" ways of doing it, you probably
won't be berated for doing it your own way.

I've worked a dozen or so different jobs and I've never been in an
organization that handles REST the same way.

There's really no "enlightenment". It's just a way to get data from one place
to another in a relatively simple way with low overhead using protocols that
already exist.

Check out SOAP. It's a standard protocol. Compare how it works to how REST
works and you'll probably pretty easily see the differences and benefits to
each.

------
dragonwriter
> RESTful APIs are dominant currently.

That depends how you define RESTful. One's conforming to the architectural
style Fielding described are quite rare.

> However, it seems to me that elements of the REST "style" are constricting
> for no reason.

While there may be debates over the merits of the reasons, nothing in REST is
without a reason.

> I see how conforming to the original intention of the HTTP methods may be
> elegant or in some way natural, but I can't summon any kind of compelling
> justification for a restriction to only GET, PUT, POST, DELETE

REST does not impose such a restriction. Heck, REST is a big reason for PATCH
and the proposed SEARCH method. OTOH, I think with PATCH and SEARCH added, the
standard HTTP methods provide a pretty complete set of operations.

OTOH, while HTTP itself _is_ a REST API, REST is not in anyway tied to HTTP or
it's set of methods.

> Using GET forces parameters to be placed in the URL; wouldn't it be nice to
> deal with only POST requests with JSON bodies?

No, it would be _better_ to have SEARCH, which is safe but takes a request
body. Also, you literally just went 180° from complaining about being limited
to _only_ four standard methods to arguing that it would be better to have
just one standard method. Without actually explaining either of those
diametrically-opposed complaints.

> Web APIs are almost always accessed programmatically anyway.

Fielding-style REST (which, to be fair, most “REST” APIs are not) is pretty
optimal for programmatic access, since it is fully self-describing and
discoverable, given that the client has handlers for th involved media types
used for resource representation.

~~~
kizer
What I failed to say when suggesting a POST only API was that the various
access methods could be encoded in the body of the request. Also I didn’t
understand that REST isn’t tied to HTTP’s methods - but rather HTTP is itself
a REST implementation... from what I understand. Thank you for that.

------
kizer
Also I’d like to clarify that this wasn’t intended as a critique of REST, nor
an argument against . I wanted to understand its motivation.

------
giardini
Kizer says> _" However, it seems to me that elements of the REST "style" are
constricting for no reason._

Probably b/c you don't understand REST and its history?

Kizer says> _" I can't summon any kind of compelling justification for a
restriction to only GET, PUT, POST, DELETE - aside from their analogy with
CRUD I guess."_

That is an invalid analogy, but your desire to know _why_ it is an invalid
analogy may motivate you. Learning about REST will enlighten you.

Kizer says> _" Could anyone please enlighten me?"_

Unfortunately enlightenment is something one must gain oneself. Google for
"Representational State Transfer REST" and follow the most interesting URLs
until the light bulb goes on. Or try:

[https://www.google.com/search?q=best+introduction+to+represe...](https://www.google.com/search?q=best+introduction+to+representational+state+transfer++REST)

~~~
kizer
I've googled and read but it's not getting through - I'm sorry. Could you
offer an answer or explanation yourself?

~~~
giardini
I think you can give it more than 22 minutes' thought before you call yourself
a failure. I'd suggest that you take a week or so perusing the literature.

There are so many excellent sources concerning REST on the Internet, I believe
you will not fail to achieve enlightenment.

~~~
x0hm
Being condescending and saying "Google it" isn't helpful. If you don't know
enough about a topic to help someone, you have no room to talk down to them.

~~~
giardini
What happened to telling someone to go to the proper sources? The good info on
REST is there on Google, or Bing, or Yahoo or DuckDuckGo. Right there, up
front.

I retrieved some old files/notes on REST today and was enjoying the memories.
But should I help someone who foolishly tosses out accusations of
condescension or another who speaks of "non-answers" when _all the answers one
needs are out there purely for the reading?_

Indeed, due to the settled nature of REST it seems hardly a suitable topic for
HN, like asking "Why SQL?" or "Why FORTRAN-77"? The thread topic question was
asked/discussed/answered in all respects nearly two decades ago. Its so old
that some information about REST is aging off the WWW and the original
participants are starting to die off (don't get your hopes up, Microsoft!).

~~~
dragonwriter
> What happened to telling someone to go to the proper sources?

Good question, why don't you trying actually doing that with references to
specific, useful sources if you think that is what is necessary?

> Indeed, due to the settled nature of REST it seems hardly a suitable topic
> for HN

If you feel it's OT, then flag and move on rather than threadcrapping.

(Also, REST is rather far from settled; a variety of different things _called_
REST are popular, but they aren't the same thing as eachother or over time,
and they often are quite distant from the architectural style Fielding
described.)

