Nicely done. How long will it take to realize that the concept of application state transfer and REST itself was a bad idea that seemed to be a good to some at the time.Hypertext as the engine of Presentation of info structures and affordances for intentional intentinteraction and the resulting transformation in coherent workflows?
HATEOAS isn't popular even in bigger APIs, when a client isn't a browser. I don't see how HTMX will embrace hypermedia, in a browser it's not necessary to show the structure of the resources.
HTMX is on the right path for sure. If you get your concept right software almost can take care of itself. After all software is a conversation and mutual learning symmathesy about intents and purposes amenable to effective articulation
the way it is explained here only points to a shift on where the knowledge is supposed to be. if hateoas provides all the details for the frontend, up to and including layout, there is too much work to provide different frontends for different devices. The common availability of JSON and JS frameworks makes it easier to share your api, without an api dev having to know every business detail to render a frontend. Maybe it is time to not use the word RESTfull anymore?
more like what happen to restful apis without hateoas. api rests demand the frontend data fetch to be independent from the back and driven by html which means real SSR. this doesnt exist in modern application architecture (w SPAs not htmx) and state managed v-doms. Roy Fielding or wtvr his name coined the term in a time where there wasnt no SPAs to a multi request system api that handles both json, xml and html. The term has continued to be used by accident to defone JSON APIs..... there ain't no api rest today, you got literally two MVCs.
The content and animations are amazing. They are very illustrative!
i think it's because of SaaS / API based business models. If you're returning html, it would be difficult for other applications consuming your api.
Damn that was really helpful. +1
Nicely done. How long will it take to realize that the concept of application state transfer and REST itself was a bad idea that seemed to be a good to some at the time.Hypertext as the engine of Presentation of info structures and affordances for intentional intentinteraction and the resulting transformation in coherent workflows?
HATEOAS isn't popular even in bigger APIs, when a client isn't a browser. I don't see how HTMX will embrace hypermedia, in a browser it's not necessary to show the structure of the resources.
Great content .. how do you make these animation presentations?
HTMX is on the right path for sure. If you get your concept right software almost can take care of itself. After all software is a conversation and mutual learning symmathesy about intents and purposes amenable to effective articulation
the way it is explained here only points to a shift on where the knowledge is supposed to be. if hateoas provides all the details for the frontend, up to and including layout, there is too much work to provide different frontends for different devices. The common availability of JSON and JS frameworks makes it easier to share your api, without an api dev having to know every business detail to render a frontend. Maybe it is time to not use the word RESTfull anymore?
please release part 2
Coming soon to TH-cam near you!
Subbed
heyyy welcome and thank you for subbing! ☺️ Stay tune for more videos!!!!
Cmon man! HTML verbs have been around since 1.0/1.1
more like what happen to restful apis without hateoas. api rests demand the frontend data fetch to be independent from the back and driven by html which means real SSR. this doesnt exist in modern application architecture (w SPAs not htmx) and state managed v-doms. Roy Fielding or wtvr his name coined the term in a time where there wasnt no SPAs to a multi request system api that handles both json, xml and html. The term has continued to be used by accident to defone JSON APIs..... there ain't no api rest today, you got literally two MVCs.