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

11–20 of 69 posts

Re: Context engineering is sleeping on the humble hyperlink

#11

Post by not_kurt_godel »

Descon wrote: post #10
not_kurt_godel wrote: post #5

Earlier quoted context omitted.

I appreciate the conceptual analogy, but that's not really HATEOAS. HATEOAS would mean your browser/client would be entirely responsible for the presentation layer, in whatever form you desired, whether it's buttons or forms or pages or not even a GUI at all, such as a chat interface.

That's a little picky, maybe it's HATEOAS + a little extra presentation sauce (the hottest HATEOAS extension!)

It's not. The whole point of HATEOAS is that the presentation can be entirely derived from the API definition, full stop.

Re: Context engineering is sleeping on the humble hyperlink

#12

Post by fellowniusmonk »

dpe82 wrote: post #9
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…

Was this recently, using something like HTMX? Or years ago using some other system (or pure/standard HTML)?

Within the last 3 years. They had their own open sourced functional typescript framework that drove the front end.

You could use whatever lightweight rendering you wanted, mostly it was very minimal react but that hardly mattered. One thing that was a positive was how little the ui rendering choice mattered.

I don't really want to say more as it's unique enough to be equivalent to naming the company itself.

Re: Context engineering is sleeping on the humble hyperlink

#13

Post by jdlshore »

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…

HATEOAS is hypertext as the engine of application state. When a person reads a webpage and follows links, it’s not HATEOAS, because the person is not an application.

HATEOAS and by-the-book REST don’t provide much practical value for writing applications. As the article says, a human has to read the spec, make sense of each endpoint’s semantics, and write code specific to those semantics. At that point you might as well hardcode the relevant URLs (with string templating where appropriate) rather than jumping through hoops and pretending every URL has to be “discovered” on the off chance that some lunatic will change the entire URL structure of your backend but somehow leave all the semantics unchanged.

The exception, as the article says, is if we don’t have to understand the spec and write custom code for each endpoint. Now we truly can have self-describing endpoints, and HATEOAS moves from a purist fantasy to something that actually makes sense.

Re: Context engineering is sleeping on the humble hyperlink

#14

Post by alexpetros »

not_kurt_godel wrote: post #5
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 appreciate the conceptual analogy, but that's not really HATEOAS. HATEOAS would mean your browser/client would be entirely responsible for the presentation layer, in whatever form you desired, whether it's buttons or forms or pages or not even a GUI at all, such as a chat interface.

> HATEOAS would mean your browser/client would be entirely responsible for the presentation layer, in whatever form you desired, whether it's buttons or forms or pages or not even a GUI at all, such as a chat interface.

Browsers can alter a webpage with your chosen CSS, interactively read webpages out loud to you, or, as is the case with all the new AI browsers, provide LLM powered "answers" about a page's contents. These are all recontextualizations made possible by the universal HATEOAS interface of HTML.

Re: Context engineering is sleeping on the humble hyperlink

#15

Post by not_kurt_godel »

alexpetros wrote: post #14
not_kurt_godel wrote: post #5

Earlier quoted context omitted.

I appreciate the conceptual analogy, but that's not really HATEOAS. HATEOAS would mean your browser/client would be entirely responsible for the presentation layer, in whatever form you desired, whether it's buttons or forms or pages or not even a GUI at all, such as a chat interface.

> HATEOAS would mean your browser/client would be entirely responsible for the presentation layer, in whatever form you desired, whether it's buttons or forms or pages or not even a GUI at all, such as a chat interface. Browsers can alter a webpage with your chosen CSS, interactively read webpages out loud to you, or, as is the case with all the new AI browsers, provide LLM powered "answers" about a page's contents.…

Altering the presentation layer is not the same thing as deriving it from a semantic API definition.

Re: Context engineering is sleeping on the humble hyperlink

#16

Post by alexpetros »

fellowniusmonk wrote: post #7
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 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 and failed to make it nice is part of why it's so useful to acknowledge as valid the one implementation that has wildly succeeded.

Re: Context engineering is sleeping on the humble hyperlink

#17

Post by alexpetros »

not_kurt_godel wrote: post #15
alexpetros wrote: post #14

Earlier quoted context omitted.

> HATEOAS would mean your browser/client would be entirely responsible for the presentation layer, in whatever form you desired, whether it's buttons or forms or pages or not even a GUI at all, such as a chat interface. Browsers can alter a webpage with your chosen CSS, interactively read webpages out loud to you, or, as is the case with all the new AI browsers, provide LLM powered "answers" about a page's contents.…

Altering the presentation layer is not the same thing as deriving it from a semantic API definition.

Altering the presentation layer is possible precisely because HTML is a semantic API definition: one broad enough to enable self-description across a variety of domains, but specific enough that those applications can still be re-contextualized according to the user's needs and preferences.

Re: Context engineering is sleeping on the humble hyperlink

#18

Post by tsimionescu »

not_kurt_godel wrote: post #5
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 appreciate the conceptual analogy, but that's not really HATEOAS. HATEOAS would mean your browser/client would be entirely responsible for the presentation layer, in whatever form you desired, whether it's buttons or forms or pages or not even a GUI at all, such as a chat interface.

The Web is not only true HATEOAS, it is in fact the motivating example for HATEOAS. Roy Fielding's paper that introduced the concept is exactly about the web, REST and HATEOAS are the architecture patterns that he introduces primarily to guide the design of HTTP for the WWW.

The concept of a HATEOAS API is also very simple: the API is defined by a communication protocol, 1 endpoint, and a series of well-defined media types. For a website, the protocol is HTTP, that 1 endpoint is /index.html, and the media types are text/html, application/javascript, image/jpeg, application/json and all of the others.

The purpose of this system is to allow the creation of clients and servers completely independently of each other, and to allow the protocols to evolve independently in subsets of clients and servers without losing interoperability. This is perfectly achieved on the web, to an almost incredible degree. There has never been, at least not in the last decades, a big where, say, Firefox can't correctly display pages severed by Microsoft IIS: every browser really works with every web server, and no browser or server dev even feels a great need to explicitly test against the others.

Re: Context engineering is sleeping on the humble hyperlink

#19

Post by alganet »

not_kurt_godel wrote: post #11
Descon wrote: post #10

Earlier quoted context omitted.

That's a little picky, maybe it's HATEOAS + a little extra presentation sauce (the hottest HATEOAS extension!)

It's not. The whole point of HATEOAS is that the presentation can be entirely derived from the API definition, full stop.

That is just wrong.

https://ics.uci.edu/~fielding/pubs/dissertation/net_arch_sty...

The server MUST be stateless, the client MAY be stateful. You can't get ETags and stuff like that without a stateful client.

Re: Context engineering is sleeping on the humble hyperlink

#20

Post by tsimionescu »

not_kurt_godel wrote: post #11
Descon wrote: post #10

Earlier quoted context omitted.

That's a little picky, maybe it's HATEOAS + a little extra presentation sauce (the hottest HATEOAS extension!)

It's not. The whole point of HATEOAS is that the presentation can be entirely derived from the API definition, full stop.

Yes, which is exactly true of the Web. There is no aspect of a web page that is not derived from the HTML+JS+CSS files served by a server.
Post reply on HN