I once attempted to implement HATEOAS many years ago after one of our senior devs got a bug up their ass about it. It was a disaster. Our clients weren't going to suddenly sprout new functionality to consume the discoverable endpoints if we changed the API, there were always going to be client-side changes to be made as well so it was an enormous exercise in futility. Ever since then HATEOAS has always felt to me like a way to design and implement APIs thought up in the ivory towers of academia, not by anyone on the ground, in the trenches at your everyday software company.
How did REST come to mean the opposite of REST?
371–380 of 393 posts
Re: How did REST come to mean the opposite of REST?
#372Earlier quoted context omitted.
The entire point of Fielding's REST was loose coupling - that you don't hard-code interactions/URLs into clients but rather discover actions/links/interaction from representations dynamically, such that the only thing a client must know a priori is a URL. "REST API" practices are criticized because they follow all the rules and brag about eg HTTP response status code semantics and whatnot, but without following HATEO…
I don't think that was the entire point. But who cares? Loose coupling is of little benefit to the client in a client-server pair that are implemented by the same company (which presumably Fielding wasn't picturing). There are other benefits people get from REST. Semantically understandable APIs, handlers that do one thing, predictable interfaces (this is close to as valuable as discoverable imo). I don't really get…
The benefit is then opening up the coupling to other clients.
Like how Reddit used to have tons of apps before they started locking down all new functionality.
Re: How did REST come to mean the opposite of REST?
#373I 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…
I don't know if you read the article. REST is a post-hoc description of how the web worked (at the time it was made). You had web pages with hyptertext content, and that included forms. The forms had fields with names and an "action" destination. The client (the browser) knows nothing about the server or even its APIs. It just knows how to send an HTTP request with parameters. In the case of forms, those parameters w…
Then they can't call it a REST API: it's not programmatic, so it's not an API
Aka somebody pulled some ancient obscure definition out of nowhere that just means _everybody_ is wrong.
Re: How did REST come to mean the opposite of REST?
#374Earlier quoted context omitted.
I dunno man, I don't see anything about "a broad network of different sites" requirement here: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc... A hyperview-based application has the exact same defining characteristic of a RESTful web application: there is a single URL that is entered, and beyond that all actions are afforded through hypermedia controls. All the information needed to traverse the servic…
If, instead of text markup, the server just sent an image of the entire UI remote-desktop style how would it be any different? You could still have a single URL that is entered, all information needed to traverse the service can be encoded in the request/responses, and no knowledge of the entire interface is needed by the client. But we have diverged pretty far from the point. Software clients using REST APIs cannot…
I don't understand why something being "niche" or "not really interesting" has any relevance when asking if it is a hypermedia technology. You assert that "it's not consuming generic REST APIs" but that's exactly what it is doing as far as I can tell, unless you define "generic" to mean "HTML".
I dunno, I'm probably not smart enough to understand what you mean. In my mind, if it satisfies the constraints outlined by Fielding in Chapter 5 of his dissertation, it's a RESTful network architecture, and, as far as I can see, hyperview satisfies those constraints.
Maybe you can simplify it for me and point to the specific constraint in there that hyperview doesn't satisfy?
Again, I'm sorry to be so dense.
Re: How did REST come to mean the opposite of REST?
#375Earlier quoted context omitted.
An API is also the interface used by humans to create programs. When you use a library, you're using its API. This sense of the term API is often lost.
True, but in this sense every code, every library and every API would be "for humans", which renders this distinction rather useless.
Not sure what you mean. Sometimes the word API is used in one sense, sometimes in another. It's a useful distinction insofar as it allows you to talk about APIs as things used by programmers. I find many developers have a hard time understanding this sense of the word API and as a result fail to apply good API design principles such as SOLID. In fact I think this is often what separates mediocre programmers from good ones.
Re: How did REST come to mean the opposite of REST?
#376Earlier quoted context omitted.
I don't think that was the entire point. But who cares? Loose coupling is of little benefit to the client in a client-server pair that are implemented by the same company (which presumably Fielding wasn't picturing). There are other benefits people get from REST. Semantically understandable APIs, handlers that do one thing, predictable interfaces (this is close to as valuable as discoverable imo). I don't really get…
The benefit is then opening up the coupling to other clients. Like how Reddit used to have tons of apps before they started locking down all new functionality.
Twitter had a ton of clients despite a REST API that was exactly like the OP was saying was not REST.
Re: How did REST come to mean the opposite of REST?
#377Earlier quoted context omitted.
If, instead of text markup, the server just sent an image of the entire UI remote-desktop style how would it be any different? You could still have a single URL that is entered, all information needed to traverse the service can be encoded in the request/responses, and no knowledge of the entire interface is needed by the client. But we have diverged pretty far from the point. Software clients using REST APIs cannot…
I don't understand why something being "niche" or "not really interesting" has any relevance when asking if it is a hypermedia technology. You assert that "it's not consuming generic REST APIs" but that's exactly what it is doing as far as I can tell, unless you define "generic" to mean "HTML". I dunno, I'm probably not smart enough to understand what you mean. In my mind, if it satisfies the constraints outlined by…
> You assert that "it's not consuming generic REST APIs" but that's exactly what it is doing as far as I can tell, unless you define "generic" to mean "HTML".
It's not consuming a weather API or a storage API or a query API. It's consuming an API designed exactly for the singular application that is being designed. It's not distributed except in the sense that it is a client/server application but it's tightly coupled to a singular implementation. A completely different environment to what the entire paper is about.
You've responded to literally the least interesting part of my comment as even accepting hyperview as a hypermedia technology doesn't negate any of the criticism of "by the book" REST. I may be guilty of caring more about whether REST as described is practical and possible then appealing to the authority of Fielding's definitions.
Re: How did REST come to mean the opposite of REST?
#378Earlier quoted context omitted.
After hastily searching for "client" and reading how it was used in several places, I would NOT say that he means a person. But I also don't think he's talking about APIs, which is what the semantic debate seems to be about in this thread. I'm not trying to undermine your point; just to clarify that I was still talking about UI vs. API.
I agree: a lot of folks don't think a hypermedia response is an API response, which maybe deserves its own essay. A hypermedia response is an API response for a hypermedia client , and additional possible API calls to the server are then discovered within that hypermedia response via hypermedia controls (e.g. links and forms) At least, that's my position, but I understand that many people would not call this an API (…
Indeed. Anyway, nice essay and thanks for the thoughtful responses.
Re: How did REST come to mean the opposite of REST?
#379Earlier quoted context omitted.
I don't understand why something being "niche" or "not really interesting" has any relevance when asking if it is a hypermedia technology. You assert that "it's not consuming generic REST APIs" but that's exactly what it is doing as far as I can tell, unless you define "generic" to mean "HTML". I dunno, I'm probably not smart enough to understand what you mean. In my mind, if it satisfies the constraints outlined by…
> You assert that "it's not consuming generic REST APIs" but that's exactly what it is doing as far as I can tell, unless you define "generic" to mean "HTML". It's not consuming a weather API or a storage API or a query API. It's consuming an API designed exactly for the singular application that is being designed. It's not distributed except in the sense that it is a client/server application but it's tightly couple…
But it isn't coupled, that's the whole point: hyperview provides a general, mobile-centric hypermedia that embeds hypermedia controls in exactly the manner that fielding describes. (sorry, I'm going to keep referring to that since that's where the definition comes from.)
Until you can show me a REST constraint that it is violating, rather than vague assertions like "an API designed for the singular application", I'm not going to grant you that the technology isn't RESTful. Any web app can have "an API designed for that singular application." I can link out to other sites, but it doesn't have to, and the fact that it does or doesn't isn't material to whether or not it is ReSTful. If it has identification of resources, manipulation of resources, self-descriptive messages and uses Hypermedia As The Engine of Application State, it's RESTful.
Here you go:
https://en.wikipedia.org/wiki/Representational_state_transfe...
Pretty simple, just show me the constraint violated by hyperview and I'll agree with you. I don't know if HyperView provides Code On Demand, but that's an optional constraint of REST, if I understand correctly.
Re: How did REST come to mean the opposite of REST?
#380Earlier quoted context omitted.
> You could go all WebDAV with status 422 for non-syntactic errors, but I am skeptical of its utility. FastAPI uses 422 for "your data is structured wrong for this schema" and it's better than sliced bread. I think the worst part about the 4xx/5xx distinction is that it doesn't really tell you whether the request is failing in a transient or permanent way (or can't tell). It would have been nice to have more leading…
Yes, maybe the distinction would be nice, but I think the existing 4xx and 5xx codes provide a reasonable baseline for building smart clients. 403, 404—log error, maybe retry later. I don’t think there’s a reasonable way for the server to distinguish transient vs permanent failures here. 429—client should back off, throttle requests. 5xx—client should back off, throttle requests. The big problem here is that from the…
[deleted]