Live data from Hacker News

How did REST come to mean the opposite of REST?

htmx.org

381–390 of 393 posts

Re: How did REST come to mean the opposite of REST?

#381

Earlier quoted context omitted.

> 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…

You make a good argument but it's unfortunately not in response to anything I'm saying.

I never said hyperview isn't RESTful. In fact, it's probably one of the few examples of a technology that follows the REST principles to the letter you're advocating for and thus why you used it as example.

Yet it's also an example of the lack of necessity of the uniform interface constraint. As the developer of everything in the application, I don't need metadata to describe the resources or self-descriptive messages. It describes everything, I as the developer, would already know. It's pointless.

Regular software clients that aren't "browsers" like hyperview, the self-description metadata don't help there either.

So I guess I'm saying the whole uniform interface constraint is completely misguided for any software that isn't some kind of browser. And then only if that browser is actually meant to be a browser.

Re: How did REST come to mean the opposite of REST?

#382

Earlier quoted context omitted.

Don’t parse the HTML, just display it. That’s what the browser does best.

What if a mobile application wants to use the API?

This to me is the real question. I don't see how you could easily create multiple clients if you're practicing what is preached in the article.

You're really tying your server to the browser at that point so things like CLI clients and mobile clients become painful to write (not impossible but ain't nobody got time for parsing HTML when browsers do a perfectly good job of it, not to mention CSS.).

Re: How did REST come to mean the opposite of REST?

#383
post #248

Earlier quoted context omitted.

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.

It's only obscure for people who arrived at the scene long after the distortion of terms already took place, and never studied where the terminology comes from.

Re: How did REST come to mean the opposite of REST?

#385
post #311

Earlier quoted context omitted.

I know you're not supposed to complain about downvotes, but seriously?! A complement about a witty comment gets me downvoted. I give up.

That's what the upvote button is for.

There is more than one way to give positive feedback. Think of it like metric buckets. Imagine you could only rate movies out of one.

Sometimes you really like something and you want to tell the person you really liked it.

This obsession people develop about the "right" way to use upvotes and comments is inane.

Re: How did REST come to mean the opposite of REST?

#386
post #370
post #362

Earlier quoted context omitted.

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 t…

> what do those links mean? […] figure out which link is mapped to which action

The meaning is expressed by the link relation, see https://news.ycombinator.com/item?id=32155744>.

> Is one of those links a link to delete the object I am viewing and one of them a link to update it?

Sure, see RFC 5023 § 11.1.

> What about the link to get a list of all the foos associated with this particular bar?

Okay, custom link relations since the existing predefined ones are insufficient. Because `foo` and `bar` are vague, I have to make up some details and can show one way to do it:

    GET /bar/this-particular HTTP/1.1
    Host: munk-a.example

    HTTP/1.1 200 OK
    Link: ; rel="type"
    Link: ; rel="/ns-rel/foo"; title="list of all the foos associated with this particular bar"
    Link: ; rel="self"
    Link: ; rel="collection /ns-rel/bar"; title="list of all bars"
    Content-Type: application/octet-stream
    …

    GET /collection/foo?filter=/bar/this-particular HTTP/1.1
    Host: munk-a.example

    HTTP/1.1 200 OK
    Link: ; rel="type"
    Link: ; rel="item /ns-rel/foo"; title="some foo"
    Link: ; rel="item /ns-rel/foo"; title="another foo"
    Link: ; rel="self start"
    Link: ; rel="next"
    Link: ; rel="last"
    Content-Type: multipart/mixed
    …
> impossible […] there isn't really a reasonable way

I'm skipping over the rant in the second paragraph which is clearly based on misunderstanding of the subject matter. Instead of baseless assertions, stick to asking questions if you don't want to make HN readers think you're an ignorant fool.

Re: How did REST come to mean the opposite of REST?

#387

Earlier quoted context omitted.

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…

You make a good argument but it's unfortunately not in response to anything I'm saying. I never said hyperview isn't RESTful. In fact, it's probably one of the few examples of a technology that follows the REST principles to the letter you're advocating for and thus why you used it as example. Yet it's also an example of the lack of necessity of the uniform interface constraint. As the developer of everything in the…

OK, then that's the core disagreement: I think the uniform interface and the benefits of a RESTful network architecture are useful even if the software you are using isn't a "browser". In the case of hyperview, a major benefit is that you can update your mobile application without redeploying the client, exactly because of that uniform interface. That's why the creator went with the RESTful approach over a more traditional mobile app network architectures.

Re: How did REST come to mean the opposite of REST?

#388
post #357
post #308

Earlier quoted context omitted.

>Where the coupling doesn’t happen is in things like resource names and locations, as far as Fielding’s thesis was concerned there’s only one location the client needs to know and it’s the root location, everything else can be obtained by navigating the service Yeah, any my point is that relies on the client (i.e. a human) being able to understand what the different links mean. A programmatic client can't do that wit…

> A programmatic client can't do that without in someway hard coding the structure of the API. That's false. Here is the HTML again, augmented with a link relation which by its nature is perfectly understandable to a program. deposits Anyone can coin a link relation on the Web, as long as its identifier is a URI. Tokens are reserved and need to be registered at IANA: https://www.iana.org/assignments/link-relations

It's understandable if you write the code for the program to understand. If it changes from deposits to credits tomorrow then your program breaks. Hence it's coupled to the server.

Re: How did REST come to mean the opposite of REST?

#389
post #388
post #357

Earlier quoted context omitted.

> A programmatic client can't do that without in someway hard coding the structure of the API. That's false. Here is the HTML again, augmented with a link relation which by its nature is perfectly understandable to a program. deposits Anyone can coin a link relation on the Web, as long as its identifier is a URI. Tokens are reserved and need to be registered at IANA: https://www.iana.org/assignments/link-relations

It's understandable if you write the code for the program to understand. If it changes from deposits to credits tomorrow then your program breaks. Hence it's coupled to the server.

There is always coupling. The question is whether a certain architectural design is coupled loosely or tightly. If you read Fielding's blog post referenced in TFA, you can see he is an advocate of loose coupling.

I have demonstrated this design in my post above.

Re: How did REST come to mean the opposite of REST?

#390

Earlier quoted context omitted.

You make a good argument but it's unfortunately not in response to anything I'm saying. I never said hyperview isn't RESTful. In fact, it's probably one of the few examples of a technology that follows the REST principles to the letter you're advocating for and thus why you used it as example. Yet it's also an example of the lack of necessity of the uniform interface constraint. As the developer of everything in the…

OK, then that's the core disagreement: I think the uniform interface and the benefits of a RESTful network architecture are useful even if the software you are using isn't a "browser". In the case of hyperview, a major benefit is that you can update your mobile application without redeploying the client, exactly because of that uniform interface. That's why the creator went with the RESTful approach over a more tradi…

There's nothing new about that model; having a client interpret an application from a server is as old as computing itself.

> I think the uniform interface and the benefits of a RESTful network architecture are useful even if the software you are using isn't a "browser".

Except it can't be used for anything other than a "browser" either a real browser or something like hyperview. That's fine but it hardly suggests that it should be necessary.

Post reply on HN