211–220 of 393 posts
A new name is needed for Classic REST. The use of HATEOAS is ugly because it has HATE in the name. Hypermedia Constraint REST is better. Stateless REST. Pure REST. Classic REST. Separation of Concerns REST. Rest 1.0. Hypermedia REST vs JSON REST
Earlier quoted context omitted.
I'd like to see a lot more humility on certainty of approach than the absolutism we often see. There's often a handful or more ways to do anything, why is there so much certainty in all contexts of the correct way. The correct way is often best defined by the unique context a given piece of software is developed within. Tradeoffs take into account more than technology alone.
dhh has a talk about this general idea. Writing software is such a _human_ thing. It has so much more in common with writing than it does with other kinds of engineering. Most of what we're doing has to do with how to lay things out so that it's clear and easy for other humans (including the humans that write code) to understand, interact with, and modify. Any time you're dealing with humans brains, there's going to…
So many leaders have an arrogance about how things must be done. They are all 100% correct and they all disagree with each other. Reminds me of diet/fitness gurus.
I never understood this and still don’t. The P in API is programmer’s. Specifically it is a programattic call. REST says you get hyperlinks, which are effectively documentation in the response. Which is nice. But a program isn’t a person it doesn’t need docs in the response. And URL links are not sufficient documentation to use the interface. So I don’t get the REST use case outside of some university AI project wher…
whether it is a local function or a remote function, both caller and callee need to agree on the parameters (input), and returns (output).
I send you X. You send me back Y. That's it - this is the contract we both agree to.
OP is saying - the caller should NEVER do anything with Y other than display it on screen, for it to be called REST. Well - why even display it, why not just discard it ? Calling print(Y) is as good as calling businesslogic(Y). Whatever further logic a human plans to do after print(Y), a machine can do the same.
In other words, REST is just step 1 of returning data from a remote function. The moment you code any additional logic on the returned data (which is 99% of use cases), it's not REST anymore ? Sounds like an extremely limited definition /use case of REST.
Because no one knows what the hell the acronym means, except that it sounds good. Everyone wants to be RESTful. RESTful is chill. It's resting - good programmers are lazy! But RESTful is resting while using an acronym , which is technical and sophisticated. To be RESTful is to be one of the smart lazy ones. Now if you're one of the few who cares what your acronyms mean, you look it up and ... "representational state…
whether it is a local function or a remote function, both caller and callee need to agree on the parameters (input), and returns (output).
I send you X. You send me back Y. That's it - this is the contract we both agree to.
OP is saying - the caller should NEVER do anything with Y other than display it on screen, for it to be called REST. Well - why even display it, why not just discard it ? Calling print(Y) is as good as calling businesslogic(Y). Whatever further logic a human plans to do after print(Y), a machine can do the same.
In other words, REST is just step 1 of returning data from a remote function. The moment you code any additional logic on the returned data (which is 99% of use cases), it's not REST anymore ? Sounds like an extremely limited definition /use case of REST.
Earlier quoted context omitted.
Fielding isn't saying the client should know nothing about the meaning of the responses. He's saying that what the client knows about the meaning of the responses is derived by interpreting them according to the media type, which doesn't have to be HTML, rather than, for example, by looking at the URL. Quoting from what Fielding wrote in his post and comments: > A REST API should be entered with no prior knowledge be…
2008 Fielding definitely wouldn't agree with me that HATEOAS is for humans. That's a conclusion I came to after watching it never catch on in the JSON API space and then trying to come up with an explanation as to why. I'd love to hear what he thinks of the idea. Thank you for the thoughtful comment!
Thanks for your thoughtful essays!
Earlier quoted context omitted.
I tend to find it helpful to ask, "is this proper REST as in HATEOAS, or is just 'REST-ish'?" It's usually just REST-ish: predefined URL patterns, roughly 1:1 with specific resource-APIs; they care about your HTTP verb and return JSON (but usually not with a lot of URLs in that JSON).
It's funny because HATEOAS violations were single-handedly the most common violation made by the client team during my time there. They loved hard coding URLs and willfully ignoring hypermedia.
bookHotelUri = listHotelResponse.data.urls[4];
listHotelResponse .data.urls.find(u=>u.action===‘book’).url
?Because no one knows what the hell the acronym means, except that it sounds good. Everyone wants to be RESTful. RESTful is chill. It's resting - good programmers are lazy! But RESTful is resting while using an acronym , which is technical and sophisticated. To be RESTful is to be one of the smart lazy ones. Now if you're one of the few who cares what your acronyms mean, you look it up and ... "representational state…
this whole discussion seems pedantic. whether it is a local function or a remote function, both caller and callee need to agree on the parameters (input), and returns (output). I send you X. You send me back Y. That's it - this is the contract we both agree to. OP is saying - the caller should NEVER do anything with Y other than display it on screen, for it to be called REST. Well - why even display it, why not just…
Sure, you can run the HTML through a browser and it looks nicer, but who cares? You can also render a JSON blob with a slightly different set of rules. And if we don't bother with the rendering on either side, it remains just as obvious what the JSON means.
If these people wanted their ideas to stand the rest of time, rather than merely the acronyms, they should have had better ideas.
Earlier quoted context omitted.
> "This would suggest a restful api is not made for system-to-system communication, but requires human mediation at every step of the way" Which is exactly what REST was originally designed to do: provide an architecture for the Internet (not your app or service) that allows for humans using software clients to interact with services developed by programmers other than those which developed the clients. It was about…
People took the useful ideas and tossed the rest. The whole idea of embedding links into the data that describe available operations was not seen as useful, because most web pages already do that . That was not a problem that needed to be solved. But the concept of resource-oriented architectures which leveraged HTTP verbs to act on data with descriptive URIs was extremely useful in an era when interactions with web…
REST, noun, acronym. 1. A term to indicate APIs that use HTTP as the transport protocol, and typically JSON as representation. 2. (archaic) A term conied in a paper from 2000, indicating a model that describes how the internet works.
Roy Fielding has no one to blame but himeself for creating such a catchy name that will definitely be reappropriated to refer to another thing. Same goes for OOP. /s
Earlier quoted context omitted.
By my read of this "REST API" is a near oxymoron. It was never supposed to be an "API" in the sense that a program consumes it. It was originally described as "Representational State Transfer (REST) architectural style for distributed hypermedia systems" with a focus on describing resources in generic ways for consumption by hypermedia systems (not arbitrary programs!). I think this is most clearly described by two t…
> describing resources in generic ways the trouble is that HTML is anything but generic. If you've ever tried to write a web scraper that can be used on _any_ webapage you quickly discover that its near impossible. I use to belived that there should be one way to use HTML to describe the page content and the rest should be CSS but gave up as its completely inflexable and the approch has been abandoned for simply desc…