daily reminder that this REST is the opposite of the original REST: https://htmx.org/essays/how-did-rest-come-to-mean-the-opposite-of-rest/ https://htmx.org/es

daily reminder that this REST is the opposite of the original REST: https://htmx.org/essays/how-did-rest-come-to-mean-the-opposite-of-rest/ https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi... and that REST, as specified by the guy who coined the term, consists of a series of constraints that can be found here: https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_st... - it must be client/server - it must be stateless - it must be cacheable - it must have a uniform interface - it must be layered - optionally, it must support code on demand The uniform interface is the most interesting and distinguishing constraint of REST, and it consists of four sub-constraints: - identification of resources - manipulation of resources through representations - self-descriptive messages - hypermedia as the engine of application state (HATEOAS) It's very uncommon for JSON APIs to satisfy the uniform interface and, in particular, for them to use HATEOAS. I have a chapter in my book that goes through the constraints of REST here: https://hypermedia.systems/hypermedia-components/ https://hypermedia.systems/hypermedia-components/ And many boorish essays on the topic here: https://htmx.org/essays/#hypermedia-and-rest https://htmx.org/essays/#hypermedia-and-rest Thank you for coming to my ted talk.