3 ms·
Ask HN: Why REST?
RESTful APIs are dominant currently. However, it seems to me that elements of the REST "style" are constricting for no 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 - aside from their analogy with CRUD I guess. Using GET forces parameters to be placed in the URL; wouldn'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.
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/methods - like RPC. Web APIs are almost always accessed programmatically anyway.
Could anyone please enlighten me?
- giardini 8y agoKizer 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+representational+state+transfer++REST https://www.google.com/search?q=best+introduction+to+represe...
- kizer 8y agoI've googled and read but it's not getting through - I'm sorry. Could you offer an answer or explanation yourself?
- giardini 8y agoI 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 8y agoBeing 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 8y agoWhat 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!).
- kizer 8y agoWhy SQL? Edit: Joking aside, I had read the information on REST. I did give it more than a few minutes' thought prior to posting. But I still did not quite understand its prevalence today; perhaps that speaks to my inability to comprehend or analyze information. Regardless, I decided to post on HN in the hopes that someone would help me out - I wasn't arguing for, nor against, REST. Could you suggest another forum where to post? What else should I do when I've read the available information and still don't "get it"?
- kizer 8y agoYou mention that such a thread was discussed ~20 years ago, and such information is so old that it's aging off the web. Considering that I was a toddler ~20 years ago, I could not have understood it then, I think. So why not start a new thread now to replace the threads aging away?
- dragonwriter 8y ago
- dragonwriter 8y ago> 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 8y agoWhat 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.
- x0hm 8y agoREST 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.
- kizer 8y agoAlso 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.