Live data from Hacker News

How Did REST Come to Mean the Opposite of REST?

htmx.org

11–13 of 13 posts

Re: How Did REST Come to Mean the Opposite of REST?

#11
post #2

To me this is gif vs gif. The populous has shifted in a direction the originator didn’t intend, but it’s the populous that use it. RESTful to me is HTTP calls with PUT/PATCH/GET/DELETE and whatever else I am missing. The return doesn’t need to be json but needs to be structured so XML, JSON, etc

Part of the nomenclature problem here is that there's no other way to refer to an HTTP-based API. REST was originally an alternative to the horrible SOAP. I'd be fine with calling it something else (because the author is right, nobody's following Fielding's vision), but there's nothing else to call it.

HTTP API?

Re: How Did REST Come to Mean the Opposite of REST?

#12
post #2

To me this is gif vs gif. The populous has shifted in a direction the originator didn’t intend, but it’s the populous that use it. RESTful to me is HTTP calls with PUT/PATCH/GET/DELETE and whatever else I am missing. The return doesn’t need to be json but needs to be structured so XML, JSON, etc

Part of the nomenclature problem here is that there's no other way to refer to an HTTP-based API. REST was originally an alternative to the horrible SOAP. I'd be fine with calling it something else (because the author is right, nobody's following Fielding's vision), but there's nothing else to call it.

"JSON-over-HTTP(S)" is a bit verbose, but accurate.

Re: How Did REST Come to Mean the Opposite of REST?

#13
post #8

Before REST gained mind share, developing for the web was effectively templating. Vanilla PHP, Java server pages, Django, Rails, etc all had this idea that business logic would be transformed server-side into complete web pages by injecting variables into HTML. REST came along and tried to put some discipline around this. The URLs now mattered and had semantic meaning! All the self-describing hypertext stuff was inte…

In addition to what you said, the idea that the endpoint should determine state and drive the possible sequence of actions is not obviously universally a good thing.

Many projects involve stringing together capability from different systems (via their api's) and creating essentially a new business layer on top of the combination of those systems. Now the abstract high level state is really managed by the new system and the component systems are just providing foundational capabilities.

The idea of HATEOS seems interesting but with limited application.

Post reply on HN