It kinda had always been comical to me that people around 2003 - 2010 were non-stop citing Fielding's paper as if he envisioned REST APIs that worked with JSON. No one actually citing the paper cared at all to read it - but skimmed it or read someone else's notes on it.
Then eventually everyone went crazy thinking their REST Api was supposed to be human readable and started adding Links to the response... and then HATEOAS was born. And it went everywhere in talks at JavaWorld and whatever else was the hot shit back in the day.
People started talking about how they would transfer money from their various bank accounts in Curl or renewing their drivers license by carefully crafting their own JSON payload by hand.
I grabbed sanity by the horns early and decided that none of it is meant for humans and rode the internet age as a developer not making more talks on PERFECT RESTFUL PATHS. I just kind of got by in meetings where people argued 30 minutes at a time about the path, slightly rolling my eyes thinking "oh gawd these are the people with a Sublime instance open with a giant DMV renewal they've been working on for weeks".
When GQL came out, I was just happy something was going to murder REST once and for all.
I think the most annoying thing about REST is the number of ways you can transmit data or intent:
And to understand the response you need to look at:
1. Status codes
2. Payload
3. Redirections
4. Continuations. egh
5. Headers again
The reason swagger/openapi is so shitty (or at least took about 20 years to become stable) is because of that.
Finally just moving a bit more into the practicality - there is nowhere in the OSI stack where the next layer up (or down depending on how you see it) cares a whole lot about the layer before it. And that's on purpose. TCP doesn't care what PORT you're running on in IP land. Yet for some reason everyone stopped thinking when HTTP was invented that it was specifically to help with WEB PAGES. It was not invented for APIs. I think GQL is a much better abstraction, and while it's bound to Http, in a sense- it can easily be repackaged on top of a different protocol in the future just by moving 1 or 2 things (mostly headers for auth).
Agreed. My take:
It kinda had always been comical to me that people around 2003 - 2010 were non-stop citing Fielding's paper as if he envisioned REST APIs that worked with JSON. No one actually citing the paper cared at all to read it - but skimmed it or read someone else's notes on it.
Then eventually everyone went crazy thinking their REST Api was supposed to be human readable and started adding Links to the response... and then HATEOAS was born. And it went everywhere in talks at JavaWorld and whatever else was the hot shit back in the day.
People started talking about how they would transfer money from their various bank accounts in Curl or renewing their drivers license by carefully crafting their own JSON payload by hand.
I grabbed sanity by the horns early and decided that none of it is meant for humans and rode the internet age as a developer not making more talks on PERFECT RESTFUL PATHS. I just kind of got by in meetings where people argued 30 minutes at a time about the path, slightly rolling my eyes thinking "oh gawd these are the people with a Sublime instance open with a giant DMV renewal they've been working on for weeks".
When GQL came out, I was just happy something was going to murder REST once and for all.
I think the most annoying thing about REST is the number of ways you can transmit data or intent:
And to understand the response you need to look at: The reason swagger/openapi is so shitty (or at least took about 20 years to become stable) is because of that.Finally just moving a bit more into the practicality - there is nowhere in the OSI stack where the next layer up (or down depending on how you see it) cares a whole lot about the layer before it. And that's on purpose. TCP doesn't care what PORT you're running on in IP land. Yet for some reason everyone stopped thinking when HTTP was invented that it was specifically to help with WEB PAGES. It was not invented for APIs. I think GQL is a much better abstraction, and while it's bound to Http, in a sense- it can easily be repackaged on top of a different protocol in the future just by moving 1 or 2 things (mostly headers for auth).
I HATE REST