6 ms·

I took a deepish dive into these kinds of issues. My interpretation is that no one uses REST properly (ie, HATEOAS). Fielding has even said so - if you aren’t d

I took a deepish dive into these kinds of issues. My interpretation is that no one uses REST properly (ie, HATEOAS). Fielding has even said so - if you aren’t designing something as big as HTTP itself, then “true” REST isn’t for you. Now there’s this thing called REST that we all commonly understand and debate over. And I have run into so many issues that I basically abandoned calling it REST and now just call it an API. And somehow it still all works just as well :)

Osiris 5y ago
Yeah I tend to refer to them as HTTP APIs.
egeozcan 5y ago
Use GET for everything that can be cached and repeated without side-effects, and POST for everything else. You can delete the rest of the spec and clients can connect without head-aches but only if you can put up with the fanatics in your team trying to trace every bug to not following rest, in the rare case giving you no options other than trying patch after patch to make everything rest-compliant.
- hakre 5y ago
  > Use GET for everything that can be cached and repeated without side-effects As long as HTTP is concerned (which must not be specifically REST), HEAD needs to be supported next to GET, too.
- nojs 5y ago
  > Use GET for everything that can be cached and repeated without side-effects *except when the query string is too big, then use POST
shroompasta 5y ago
True. I have personally gone off the deep end and started writing 200, 400, and 500 for all my status codes instead of the specific 2xx, 4xx, 5xx ones. If details of an error response need to be mentioned, it will be in the error response body. My motivation came from GraphQL as it responds everything with 200s, and so far it has been humming along fine. True REST are more guidelines if anything.
- capableweb 5y ago
  > My motivation came from GraphQL as it responds everything with 200s, and so far it has been humming along fine. This is slightly annoying though, as other consumers (like `fetch` in JavaScript world for example) behaves differently if there is a error. If every status is 200, suddenly you need to manually check the response inside the returned promise, while if you answer with a correct status code when the server encountered an error (5xx), then it'll jump to the `.catch` part of the promise chain instead, which you're probably already handling anyways. Similarly with curl if I'm not mistaken (don't have it in front of me). A 2xx would make the process return 0, while a 5xx would make it return non-0, so you can handle errors without having to read the actual response.
  - hakre 5y ago
    That must be something fetch specific, per the HTTP specs IIRC, any status code should be passed to the application - and the way I read it - unfiltered. It is neither an error nor an exception, the request is successful. A DNS or server connection issue would not be. Similar with curl, 502 returns non-zero, 302 not. 4xx IIRC as well zero unless --fail is in use. The default makes it sensible/useful for smoke tests. Perhaps GraphQL was aware of such client side "bugs" it choose to go "OK" first of all.
  - beardedetim 5y ago
    Yes. Yes Yes yes. Status code is important beyond your eyes and your hand-rolled api interactions. I can't believe the people here saying "fuck it, I always return 200"
- reidjs 5y ago
  That part of GQL drives me nuts. How the heck do people do error handling on the frontend with API requests through GQL? Instead of `try catch`, do you do `if (response.error) {}`?
  - samsonradu 5y ago
    Yes, can be handled with middleware (interceptors) that throw the `response.error`
morelish 5y ago
My interpretation is that REST is such a complicated definition that no-one bothers to understand it. It's just too complicated (insert reference to Fielding dissertation). At least, whatever Fielding wrote, terms and languages are too esoteric for people including me to bother with it. REST is now in practice an API using JSON over HTTP with appropriate verbs. And it's 'stateless' in that the server doesn't have to track the clients prior requests to understand the current request. That's about it I think.... Does anyone think that's stupid?
feoren 5y ago
> My interpretation is that no one uses REST properly (ie, HATEOAS). Agreed that everyone ignores the HATEOAS clause of REST, even when they call things "RESTful", but that's because the HATEOAS clause is tremendously stupid. I don't know why it's so common for narrow-minded intellectuals to decide that the reason the world is so complicated is because nobody has sat down yet and decided to make it simple. No, the world is complicated because reality has a surprising amount of detail [1][2]. When one person (or worse, a committee) sits down and decides "this is the way all of the world's information will be organized from now on" (HATEOAS, the "semantic web", etc.) they envision automated tools that can browse information the way Web Browsers browse the web. But as complicated as HTTP, HTML, CSS, JS, CORS, SVG, and now WebAssembly are, they are dozens of orders of magnitude simpler than "all the information anyone might ever want to make available over an API". Writing hypertext that can be understood by a tool to digest how your API should be consumed is just not possible. It doesn't work for people who are new to the API (they need to read the docs no matter what), and it's useless overhead for the people who use the API all the time (the hypertext is delivered with every request!?) People don't use HATEOAS because HATEOAS is stupid. [1] http://johnsalvatier.org/blog/2017/reality-has-a-surprising-amount-of-detail http://johnsalvatier.org/blog/2017/reality-has-a-surprising-... [2] https://wiki.c2.com/?WhyIsPayrollHard https://wiki.c2.com/?WhyIsPayrollHard

Osiris 5y ago

Yeah I tend to refer to them as HTTP APIs.

egeozcan 5y ago

Use GET for everything that can be cached and repeated without side-effects, and POST for everything else. You can delete the rest of the spec and clients can connect without head-aches but only if you can put up with the fanatics in your team trying to trace every bug to not following rest, in the rare case giving you no options other than trying patch after patch to make everything rest-compliant.

hakre 5y ago
> Use GET for everything that can be cached and repeated without side-effects As long as HTTP is concerned (which must not be specifically REST), HEAD needs to be supported next to GET, too.
nojs 5y ago
> Use GET for everything that can be cached and repeated without side-effects *except when the query string is too big, then use POST

shroompasta 5y ago

True. I have personally gone off the deep end and started writing 200, 400, and 500 for all my status codes instead of the specific 2xx, 4xx, 5xx ones. If details of an error response need to be mentioned, it will be in the error response body. My motivation came from GraphQL as it responds everything with 200s, and so far it has been humming along fine. True REST are more guidelines if anything.

capableweb 5y ago
> My motivation came from GraphQL as it responds everything with 200s, and so far it has been humming along fine. This is slightly annoying though, as other consumers (like `fetch` in JavaScript world for example) behaves differently if there is a error. If every status is 200, suddenly you need to manually check the response inside the returned promise, while if you answer with a correct status code when the server encountered an error (5xx), then it'll jump to the `.catch` part of the promise chain instead, which you're probably already handling anyways. Similarly with curl if I'm not mistaken (don't have it in front of me). A 2xx would make the process return 0, while a 5xx would make it return non-0, so you can handle errors without having to read the actual response.
- hakre 5y ago
  That must be something fetch specific, per the HTTP specs IIRC, any status code should be passed to the application - and the way I read it - unfiltered. It is neither an error nor an exception, the request is successful. A DNS or server connection issue would not be. Similar with curl, 502 returns non-zero, 302 not. 4xx IIRC as well zero unless --fail is in use. The default makes it sensible/useful for smoke tests. Perhaps GraphQL was aware of such client side "bugs" it choose to go "OK" first of all.
- beardedetim 5y ago
  Yes. Yes Yes yes. Status code is important beyond your eyes and your hand-rolled api interactions. I can't believe the people here saying "fuck it, I always return 200"
reidjs 5y ago
That part of GQL drives me nuts. How the heck do people do error handling on the frontend with API requests through GQL? Instead of `try catch`, do you do `if (response.error) {}`?
- samsonradu 5y ago
  Yes, can be handled with middleware (interceptors) that throw the `response.error`

morelish 5y ago

My interpretation is that REST is such a complicated definition that no-one bothers to understand it. It's just too complicated (insert reference to Fielding dissertation). At least, whatever Fielding wrote, terms and languages are too esoteric for people including me to bother with it. REST is now in practice an API using JSON over HTTP with appropriate verbs. And it's 'stateless' in that the server doesn't have to track the clients prior requests to understand the current request. That's about it I think.... Does anyone think that's stupid?

feoren 5y ago

> My interpretation is that no one uses REST properly (ie, HATEOAS). Agreed that everyone ignores the HATEOAS clause of REST, even when they call things "RESTful", but that's because the HATEOAS clause is tremendously stupid. I don't know why it's so common for narrow-minded intellectuals to decide that the reason the world is so complicated is because nobody has sat down yet and decided to make it simple. No, the world is complicated because reality has a surprising amount of detail [1][2]. When one person (or worse, a committee) sits down and decides "this is the way all of the world's information will be organized from now on" (HATEOAS, the "semantic web", etc.) they envision automated tools that can browse information the way Web Browsers browse the web. But as complicated as HTTP, HTML, CSS, JS, CORS, SVG, and now WebAssembly are, they are dozens of orders of magnitude simpler than "all the information anyone might ever want to make available over an API". Writing hypertext that can be understood by a tool to digest how your API should be consumed is just not possible. It doesn't work for people who are new to the API (they need to read the docs no matter what), and it's useless overhead for the people who use the API all the time (the hypertext is delivered with every request!?) People don't use HATEOAS because HATEOAS is stupid. [1] http://johnsalvatier.org/blog/2017/reality-has-a-surprising-amount-of-detail http://johnsalvatier.org/blog/2017/reality-has-a-surprising-... [2] https://wiki.c2.com/?WhyIsPayrollHard https://wiki.c2.com/?WhyIsPayrollHard