Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Context engineering is sleeping on the humble hyperlink

mbleigh.dev

Post reply on HN
Print view View original

21–30 of 69 posts

Re: Context engineering is sleeping on the humble hyperlink

#21

Post by tsimionescu »

not_kurt_godel wrote: post #8
ffsm8 wrote: post #6

Earlier quoted context omitted.

From what I read on wiki, I'm not sure what to think anymore - it does at least sound inline with the opinion that the current websites are actually HATeOAS. I guess someone interested would have to read the original work by Roy (who seems to have come up with the term) to find out which opinion is true

I worked on frontend projects and API designs directly related to trying to achieve HATEOAS, in a general, practical sense, for years. Browsing the modern web is not it.

I think you are confusing the browser with the web page. You probably think that the Javascript code executed by your browser is part of the "client" in the REST architecture - which is simply not what we're talking about. When analyzing the WWW, the REST API interface is the interface between the web browser and the web server, i.e. the interface between, say, Safari and Apache. The web browser accesses a single endpoint on the server with no prior knowledge of what that endpoint represents, downloads a file from the server, analyzes the Content-Type, and can show the user what the server intends to show based on that Content-Type. The fact that one of these content types is a language for running server-controlled code doesn't influence this one bit.

The only thing that would have made the web not conform to HATEOAS were if browsers had to have code that's specific to, say, google.com, or maybe to Apache servers. The only example of anything like this on the modern web is the special log in integrations that Microsoft and Google added for their own web properties - that is indeed a break of the HATEOAS paradigm.

Re: Context engineering is sleeping on the humble hyperlink

#22

Post by mbleigh »

alexpetros wrote: post #3

> Purists have long claimed that a “truly” RESTful API should be fully self-describing, such that a client can explore and interact with it knowing nothing but an entrypoint in advance, with hyperlinks providing all necessary context to discover and consume additional endpoints. > This never worked in practice. Building hypertext APIs was too cumbersome and to actually consume APIs a human needed to understand the AP…

Totally agree, the web itself is absolutely HATEOAS, but there was a type of person in the 2000s era who insisted that APIs were not truly RESTful if they weren't also hypermedia APIs, but the only real benefit of those APIs was to enable overly generic API clients that were usually strictly worse than even clumsily tailored custom clients.

The missing piece was having machines that could handle enough ambiguity to "understand" the structure of the API without it needing to be generic to the point of uselessness.

Re: Context engineering is sleeping on the humble hyperlink

#23

Post by JimDabell »

alexpetros wrote: post #3

> Purists have long claimed that a “truly” RESTful API should be fully self-describing, such that a client can explore and interact with it knowing nothing but an entrypoint in advance, with hyperlinks providing all necessary context to discover and consume additional endpoints. > This never worked in practice. Building hypertext APIs was too cumbersome and to actually consume APIs a human needed to understand the AP…

I agree. The “purist” REST using HATEOAS is the single most successful API architectural style in history by miles. It’s the foundation of the World-Wide Web, which would not have been anywhere near as successful with a different approach.

Re: Context engineering is sleeping on the humble hyperlink

#24

Post by JimDabell »

mbleigh wrote: post #22
alexpetros wrote: post #3

> Purists have long claimed that a “truly” RESTful API should be fully self-describing, such that a client can explore and interact with it knowing nothing but an entrypoint in advance, with hyperlinks providing all necessary context to discover and consume additional endpoints. > This never worked in practice. Building hypertext APIs was too cumbersome and to actually consume APIs a human needed to understand the AP…

Totally agree, the web itself is absolutely HATEOAS, but there was a type of person in the 2000s era who insisted that APIs were not truly RESTful if they weren't also hypermedia APIs, but the only real benefit of those APIs was to enable overly generic API clients that were usually strictly worse than even clumsily tailored custom clients. The missing piece was having machines that could handle enough ambiguity to "…

> there was a type of person in the 2000s era who insisted that APIs were not truly RESTful if they weren't also hypermedia APIs

The creator of REST, Roy Fielding, literally said this loud and clear:

> REST APIs must be hypertext-driven

> What needs to be done to make the REST architectural style clear on the notion that hypertext is a constraint? In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period.

— https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...

I think of all the people in the world, the creator of REST gets to say what is and isn’t REST.

Re: Context engineering is sleeping on the humble hyperlink

#25

Post by _kidlike »

alexpetros wrote: post #3

> Purists have long claimed that a “truly” RESTful API should be fully self-describing, such that a client can explore and interact with it knowing nothing but an entrypoint in advance, with hyperlinks providing all necessary context to discover and consume additional endpoints. > This never worked in practice. Building hypertext APIs was too cumbersome and to actually consume APIs a human needed to understand the AP…

I think you're misunderstanding the purpose of hateoas.

If we jump down to the bolts and nuts, let's say on a json API, it's about including extra attributes/fields in your json response that contain links and information of how to continue. These attributes have to be blended with your other real attributes.

For example if you just created a resource with a POST endpoint, you can include a link to GET the freshly created resource ("_fetch"), a link to delete it ("_delete"), a link to list all resources of the same collection ("_list"), etc...

Then the client application is supposed to automatically discover the API's functionality. In case of a UI, it's supposed to automatically discover the API's functionality and build a presentation layer on the fly, which the user can see and use. From our example above, the UI codebase would never have a "delete" resource button, it would have a generic button which would be created and placed on the UI based on the _delete field coming back from the API

Re: Context engineering is sleeping on the humble hyperlink

#26

Post by fellowniusmonk »

alexpetros wrote: post #16
fellowniusmonk wrote: post #7

Earlier quoted context omitted.

I worked for a company that was all hateoas. In the formal sense, explicitly structured around the concept, not the sense that html has both data and actions via links, it worked, it was a real product, but it was slow and terrible to develop and debug. The front end ui was entirely driven, ui and functionality exposed by the data/action payload. I'm still not sure if it's because of the implementation or because the…

> I worked for a company that was all hateoas. In the formal sense, explicitly structured around the concept, not the sense that html has both data and actions via links, it worked, it was a real product, but it was slow and terrible to develop and debug. The web is also a real product, one that's (when not bloated with adtech) capable of being fast and easy to develop on. That other people have tried to do HATEOAS a…

I do just want to be clear because I'm not 100% following I don't think.

You aren't saying hypermedia/hyperlinks served by a backend equal hateaos are you?

hateaos is from 2000 isn't it? Long after hyperlinks and the web already existed.

Re: Context engineering is sleeping on the humble hyperlink

#27

Post by tmoravec »

labrador wrote: post #4

I just discovered that I can paste a link into a Claude prompt and ask it to follow read the page so we can talk about it. I no longer have to copy the text of the page and paste it in. Claude uses the web_fetch command. So we're heading in the direction this article discusses.

Except that more often than not, Claude is blocked from reading the article.

This used to work great two years ago when chatgpt first got the Web browsing feature. Nowadays, no eyeballs on ads: no content.

Re: Context engineering is sleeping on the humble hyperlink

#28

Post by hollerith »

tmoravec wrote: post #27
labrador wrote: post #4

I just discovered that I can paste a link into a Claude prompt and ask it to follow read the page so we can talk about it. I no longer have to copy the text of the page and paste it in. Claude uses the web_fetch command. So we're heading in the direction this article discusses.

Except that more often than not, Claude is blocked from reading the article. This used to work great two years ago when chatgpt first got the Web browsing feature. Nowadays, no eyeballs on ads: no content.

Is one of the reasons OpenAI made a browser (Atlas) and Perplexity made Comet and Anthropic made a Chrome extension to make it impossible for the site to tell whether a person or the person's AI assistant is making the request?

Re: Context engineering is sleeping on the humble hyperlink

#29

Post by dragonwriter »

fellowniusmonk wrote: post #26
alexpetros wrote: post #16

Earlier quoted context omitted.

> I worked for a company that was all hateoas. In the formal sense, explicitly structured around the concept, not the sense that html has both data and actions via links, it worked, it was a real product, but it was slow and terrible to develop and debug. The web is also a real product, one that's (when not bloated with adtech) capable of being fast and easy to develop on. That other people have tried to do HATEOAS a…

I do just want to be clear because I'm not 100% following I don't think. You aren't saying hypermedia/hyperlinks served by a backend equal hateaos are you? hateaos is from 2000 isn't it? Long after hyperlinks and the web already existed.

REST, including HATEOAS, was largely retrospective documentation of the architectural underpinning of the WWW by Roy Fielding (who played an important role in web technology from 1993 on, was the co-lead for the HTTP/1.0 spec, the lead for the original HTTP/1.1 spec, and also, IIRC, lead or co-lead on the original URL spec. The things it documented existed before it documented them.

Re: Context engineering is sleeping on the humble hyperlink

#30

Post by masklinn »

fellowniusmonk wrote: post #26
alexpetros wrote: post #16

Earlier quoted context omitted.

> I worked for a company that was all hateoas. In the formal sense, explicitly structured around the concept, not the sense that html has both data and actions via links, it worked, it was a real product, but it was slow and terrible to develop and debug. The web is also a real product, one that's (when not bloated with adtech) capable of being fast and easy to develop on. That other people have tried to do HATEOAS a…

I do just want to be clear because I'm not 100% following I don't think. You aren't saying hypermedia/hyperlinks served by a backend equal hateaos are you? hateaos is from 2000 isn't it? Long after hyperlinks and the web already existed.

> You aren't saying hypermedia/hyperlinks served by a backend equal hateaos are you?

That’s exactly what it is.

> hateaos is from 2000 isn't it? Long after hyperlinks and the web already existed.

> Over the past six years, the REST architectural style has been used to guide the design and development of the architecture for the modern Web, as presented in Chapter 6. This work was done in conjunction with my authoring of the Internet standards for the Hypertext Transfer Protocol (HTTP) and Uniform Resource Identifiers (URI), the two specifications that define the generic interface used by all component interactions on the Web.

This is straight from the intro of fielding’s doctoral dissertation.

Post reply on HN