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.
(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.
Personally I think GraphQL's existence, while seemingly blatantly obvious in retrospect, is was what REST should have been. It lets "generic" applications to discover the API and its associated operations. Essentially its also simply a re-do of what Swagger (and a few others) attempted to do, but never really made REST work (imho).
> 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?).
That's the thing about REST; you don't need any rules about what paths look like, because you shouldn't be constructing them manually. You get them from the State that was Transferred to you.
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.
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.
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.
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.
I've found it's best to let other organizations be the guinea pigs and get the kinks out, or disprove it, before our own org adopts it. Too many get carried away with "new ideas" and dive in the deep-end blindfolded. Let it run "five years in a similar organization" is my time-proven rule of thumb. Unfortunately, I lack rank to enforce this rule.
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).
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.
`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.
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.
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.
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...
> 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.
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.
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])
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.
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.
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.
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.
[+] [-] ppeetteerr|7 years ago|reply
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|7 years ago|reply
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.
[+] [-] batoure|7 years ago|reply
I have always hoped to some day stumble across some madlad who scales a large production system on the back of DELETE
Although sadly browsers are starting to enforce the behaviors of verbs more and more...
Someone hurry up and get coding
[+] [-] rhacker|7 years ago|reply
Here's a good analogy:
Graphql is docker, REST is LXC.
[+] [-] danellis|7 years ago|reply
That's the thing about REST; you don't need any rules about what paths look like, because you shouldn't be constructing them manually. You get them from the State that was Transferred to you.
[+] [-] coldtea|7 years ago|reply
One thing that upsets me is pop psychology and second guessing of emotions (about "being upset", "excessively angry", etc) instead of arguments.
>Have fun with it.
Engineering is not about having arbitrary fun with whatever "standard" we are given.
[+] [-] nicc|7 years ago|reply
I personally like PUT even for delta updates, but a dev I was working with was obsessed with wanting PATCH.
[+] [-] psadauskas|7 years ago|reply
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:
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|7 years ago|reply
[+] [-] restdoesnotsuck|7 years ago|reply
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/05/08/hatoeas-is-for-humans.ht...
[+] [-] droussel|7 years ago|reply
[+] [-] interesthrow2|7 years ago|reply
[+] [-] tabtab|7 years ago|reply
[+] [-] paulddraper|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] madmaniak|7 years ago|reply
[+] [-] amaccuish|7 years ago|reply
[+] [-] thinkingkong|7 years ago|reply
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|7 years ago|reply
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.
[+] [-] leeoniya|7 years ago|reply
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|7 years ago|reply
[+] [-] crazygringo|7 years ago|reply
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...
[+] [-] crooked-v|7 years ago|reply
...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|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] teliskr|7 years ago|reply
REST is simple, simple is good. It's not perfect for everything, but it has served my purposes well for many years.
[+] [-] revskill|7 years ago|reply
[+] [-] maxxxxx|7 years ago|reply
[+] [-] batoure|7 years ago|reply
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.
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] shironineja__|7 years ago|reply
[deleted]
[+] [-] tuespetre|7 years ago|reply
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|7 years ago|reply
Archive link https://web.archive.org/web/20181028175819/http://vmrcre.org...
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__|7 years ago|reply
I define my schema, sprinkle some directives and push it to AppSync.
[+] [-] teen|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] crescentfresh|7 years ago|reply
[+] [-] daxfohl|7 years ago|reply