I need to make a SPA and it's requisite backend. Which highfalutin theory of API should I use?
How did REST come to mean the opposite of REST?
361–370 of 393 posts
Re: How did REST come to mean the opposite of REST?
#362Earlier quoted context omitted.
> GitHub’s REST api is pretty self discoverable fwiw. I had a look at the example response to see whether that is true. I give you that there are hyperlinks existing in resources of media type `application/vnd.github+json`, but there is no uniform interface to discover a link. Fielding would disapprove. It's an indication of bad design that a client must hardcode e.g. `labels_url` instead of having a generic reusable…
Wouldn't any interface to discover links need to be hardcoded? IIRC, REST didn't actually define a unified way to describe where the links existed in the returned document.
That's because you're looking at the wrong place, that's not the responsibility of REST: it can't because it's not a specification, but a description of an architectural style.
Instead, it's the responsibility of the media type. HTML offers hypermedia controls: hyperlinks are denoted with , , , elements and the "href" attribute; forms are denoted with the element as its "action" attribute. I assume you are familiar with HTML, you can see that this is a very generalised way to find links (or controls in general), it is applicable to all HTML documents. XML has close analogues: XLink and XForms. JSON-done-right offers hypermedia controls: moral equivalent of links https://datatracker.ietf.org/doc/html/draft-kelly-json-hal#s...>, moral equivalent of forms https://rwcbook.github.io/hal-forms/>. It is easy to reimagine `application/vnd.github+json` in the guise of this media type so that the problem I was describing earlier disappears. If a media type cannot express hypermedia controls or link relations inline (e.g. WebP images), then the HTTP header can be used instead, see RFCs 8288 and 6570.
Re: How did REST come to mean the opposite of REST?
#363Earlier quoted context omitted.
EXACTLY. Regurgitators of the HATEOAS mantra never address this. Instead you get statements like one in this article: "the HTML response "carries along" all the API information necessary to continue interacting with the system directly within itself." No, it doesn't. It's a list of URLs, which doesn't even indicate what operations they accept. The only thing REST supports, according to this philosophy, is a user manu…
> It's a list of URLs, which doesn't even indicate what operations they accept. HTTP does not require a particular media type's representation to indicate the allowed methods. What made you think this should be the case? All popular media types I know either contain a partial indication (e.g. forms in HTML), and otherwise a fallback to GET/HEAD as default is implied or specified. If a client is unsure, there's always…
I never said HTTP required that. The point of this discussion is that a remote COMPUTER can't derive the means of using a URL simply because it's listed. What query parameters does it support for a GET operation, for example.
This is about APIs, not bog-standard HTTP.
Re: How did REST come to mean the opposite of REST?
#364Earlier quoted context omitted.
Would you say that, in this paper, when Fielding says "client", he means "a person"? https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc... Or would the browser be the client?
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 (maybe just a RESTful system?) The language here is pretty darned academic, and Fielding didn't apologize for that:
https://roy.gbiv.com/untangled/2008/specialization
Unfortunately I think that unwillingness to come down a few pegs in abstraction ended up costing a lot in terms of confusion.
Re: How did REST come to mean the opposite of REST?
#365Earlier quoted context omitted.
I don't see how you can say it isn't a hypermedia client: it is a client that interprets hypermedia, just like the canonical hypermedia client, a web browser. It's not an internet hypermedia client like a browser, with general access to a broad network of different sites/applications, but the core mechanic satisfies REST and the format being transferred is a hypermedia.
Because it's doesn't have general access to a broad network of different sites/applications it's not a hypermedia client. It's a client for a single service that uses hypermedia is an implementation detail. An HTML client that can only view Facebook is not a browser, it's a Facebook client. The point of the article is about how REST should contain all the information needed to traverse a service. But hyperview is for…
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 service is encoded in responses, and no knowledge of the entire interface is needed by the client. Seems relevant to me.
I certainly agree it isn't a general purpose browser, but web browsers are only an instance of a hypermedia client, not the definition of one.
Re: How did REST come to mean the opposite of REST?
#366Have I understood idea of REST that described in the article right? I still have some documented "route" to resource, but instead of mapping it trivially to URL (as done in "pseudo-REST"), client requests entry point, then goes through labelled hyperlinks and forms according to "route" to reach resource. It makes sense as it allows implementation of seamless API across multiple servers and removes need to make consis…
> I still have some documented "route" to resource, but instead of mapping it trivially to URL (as done in "pseudo-REST"), client requests entry point, then goes through labelled hyperlinks and forms according to "route" to reach resource.
The basic idea is correct, the wording is not. Resources have identifiers, not routes. Hyperlinks have link relations, not labels.
> won't it add too much overhead
What overhead?
Re: How did REST come to mean the opposite of REST?
#367Re: How did REST come to mean the opposite of REST?
#368Earlier quoted context omitted.
> It's a list of URLs, which doesn't even indicate what operations they accept. HTTP does not require a particular media type's representation to indicate the allowed methods. What made you think this should be the case? All popular media types I know either contain a partial indication (e.g. forms in HTML), and otherwise a fallback to GET/HEAD as default is implied or specified. If a client is unsure, there's always…
I never said HTTP required that. The point of this discussion is that a remote COMPUTER can't derive the means of using a URL simply because it's listed. What query parameters does it support for a GET operation, for example. This is about APIs, not bog-standard HTTP.
Oh, I see. The response carries along all the information necessary to continue interacting with the system directly within itself. For example, in HTML there are forms for the purpose you just mentioned, I'll give you two examples:
10
20
50
The same idea applies to other media types.
Re: How did REST come to mean the opposite of REST?
#369Earlier quoted context omitted.
Because it's doesn't have general access to a broad network of different sites/applications it's not a hypermedia client. It's a client for a single service that uses hypermedia is an implementation detail. An HTML client that can only view Facebook is not a browser, it's a Facebook client. The point of the article is about how REST should contain all the information needed to traverse a service. But hyperview is for…
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 use the self-describing nature of REST so to claim they're all using it incorrectly I don't believe is a valid criticism. Browser-like clients, and you can include hyperview in that, can use the self-describing nature because they're pushing all the understanding to the user. But that is such a niche experience (outside of HTML browsers) that it isn't even worth discussing. For hyperview, it's not consuming generic REST APIs -- it's just acting as mobile-specific browser for a single service. That's why I said it's not really interesting.
Re: How did REST come to mean the opposite of REST?
#370Earlier quoted context omitted.
Wouldn't any interface to discover links need to be hardcoded? IIRC, REST didn't actually define a unified way to describe where the links existed in the returned document.
That's because you're looking at the wrong place, that's not the responsibility of REST: it can't because it's not a specification, but a description of an architectural style. Instead, it's the responsibility of the media type. HTML offers hypermedia controls: hyperlinks are denoted with , , , elements and the "href" attribute; forms are denoted with the element as its "action" attribute. I assume you are familiar w…
I can run a regex to find tags as well as the next guy[1] but what do those links mean? Is one of those links a link to delete the object I am viewing and one of them a link to update it? What about the link to get a list of all the foos associated with this particular bar? How am I supposed to parse this blob of HTML programmatically to figure out which link is mapped to which action?
I think this is where I think the big failing of original REST comes into play - these self-discoverable actions are sort of impossible to actually leverage... either you're hardcoding some information about the format (i.e. look for the ) or you're automatically deriving the link anyways... there isn't really a reasonable way for REST to work where these links are self-descriptive enough for a machine to figure out on their own so... in the end... why not just separate that information out into a nicely formatted API document that the devs can have on hand while building their interoperable tool? 1. And personally prefer to always parse my HTML with regexes of course...