It's time to put REST to rest
sollecitom.github.io
It's time to put REST to rest
1–10 of 85 posts
Re: It's time to put REST to rest
#2Re: It's time to put REST to rest
#3Having used “REST” for 10 years or so I can confidently say I’ve never used REST
Re: It's time to put REST to rest
#4If I had to guess, the comments here are going to revolve around "that's not REST" and "where's the hypermedia."
I think that ship has sailed. REST in practice just means following HTTP semantics.
Re: It's time to put REST to rest
#5First put SOAP and GraphQL to rest. Then we can talk
Re: It's time to put REST to rest
#6If you’re designing something right now, I want to remind you of one piece of shared but uncommon wisdom:
So many of your users will not make it much past the elevator pitch for your idea. They will feel willfully or even recklessly entitled to the notion that if your tool allows something, the.n it was meant to be used that way.
I don’t have any quick fixes for that. I doubt they exist. There are some very clever things I have seen in the REST domain that are lumped under advanced topics that make a lot of sense but I don’t think I have ever seen in the wild. So if an idea feels important, you have to aim it at the journeyman if you expect it to be used at all, and beginner if you can figure out how without losing them.
Re: It's time to put REST to rest
#7OK OK OK, OK OK, stay calm, Carson, stay calm...
I'd like to just leave a few links on REST here for the reader's consideration:
https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...
https://intercoolerjs.org/2016/01/18/rescuing-rest.html
https://htmx.org/essays/two-approaches-to-decoupling/
https://htmx.org/essays/hypermedia-apis-vs-data-apis/
https://htmx.org/essays/hypermedia-clients/
https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...
https://htmx.org/essays/hateoas/
In addition, I’d just like to interject for a moment. What you’re referring to as REST, is in fact, JSON/RPC, or as I’ve recently taken to calling it, REST-less. JSON is not a hypermedia unto itself, but rather a plain data format made useful by out of band information as defined by swagger documentation or similar.
Many computer users work with a canonical version of REST every day, without realizing it. Through a peculiar turn of events, the version of REST which is widely used today is often called “The Web”, and many of its users are not aware that it is basically the REST-ful architecture, defined by Roy Fielding.
There really is a REST, and these people are using it, but it is just a part of The Web they use. REST is the network architecture: hypermedia encodes the state of resources for hypermedia clients. JSON is an essential part of Single Page Applications, but useless by itself; it can only function in the context of a complete API specification. JSON is normally used in combination with SPA libraries: the whole system is basically RPC with JSON added, or JSON/RPC. All these so-called “REST-ful” APIs are really JSON/RPC.
Re: It's time to put REST to rest
#8Having used “REST” for 10 years or so I can confidently say I’ve never used REST
Yea. I assume from the article it's an alias for an HTTP interface that usually uses JSON payloads. I use those in a few projects, both work and personal. Are they Rest? Maybe. They use Django REST framework. But I think of them and describe them as HTTP APIs.
Re: It's time to put REST to rest
#9Those 2 were never the claimed benefits, and the fundamental "problem" is not a problem: a LOT of data processing is making changes to records. And you can encapsulate a lot of logic behind making changes to records.
And this makes most software easier to understand:
"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious." -- Fred Brooks
Re: It's time to put REST to rest
#10I’ve been having a good time using REST level 0.5
https://faithlife.codes/blog/2023/09/rest-level-zero-dot-fiv...