People make a lot as their side projects through the easy parsing, what software is being made with them? (besides the usual hacker news backend response)
I really wish HATEOAS clients were the norm instead of concatenating strings like cavemen in order to obtain a URL. You could send the prev, next, first, and last relations of your collection resource. You could also send a templated link so the clients could still jump to whatever page they want.
The thing that always puzzled me about HATEOAS was that it basically treats the computer like a human - like yes, if I'm manually exploring an API via curl, the "relation" links can be immensely helpful (sometimes - often, the bare relation names can't be understood on their own).
But if I'm having some script or app consume the API, then this script will have to "know in advance" how the API works anyway, and the "self-discoverability" of HATEOAS doesn't bring any benefit.
(There is the idea, that we could at some point have a rich set of standardized relation types and a class of generic clients that could make use of them. But as with the Semantic Web, the incentives seem to be misaligned to make that dream a reality)
But interestingly, with LLMs, the picture could change - because LLMs could actually explore the API "like a human" and even read plain-english apidocs of nonstandard relation types. So maybe some sort of LLM-augmented generic client could actually fulfill the role of the elusive "autonomous agent" that HATEOAS and Semantic Web people are designing for.
> then this script will have to "know in advance" how the API works anyway, and the "self-discoverability" of HATEOAS doesn't bring any benefit.
Tentatively, it allows better flexibility in non-entrypoint URIs, by adding a layer of indirection: instead of hardcoding URLs itself, you hardcode the name of the fields in the response that will contain actual URIs to follow.
But then there is a whole crowd of people who claim that URIs should never change anyhow, for any reason, in the first place.
That makes sense, but then it also trusts that every client will "play by the rules" - first do the "discovery" request, then use the discovered URL to do the real request - when they could just "cheat" and hardcode the URL.
I think, again the incentives are misaligned, because hardcoding would be beneficial for the client devs in several ways: It's simpler to code, halves the number of requests at runtime and gets rid of several edge cases that you'd have to deal with - e.g. what happens if the discovered URL points to a different domain than the entrypoint?
It makes sense from the server's POV, but because of this, I see a hard time to convince client devs to adopt it.
> e.g. what happens if the discovered URL points to a different domain than the entrypoint?
You follow it. Not sure why even mention it: having a web of URLs spread between e.g. contoso-streaming.tv, api.contoso.com, login.contoso.org, etc. is nothing special these days.
Clients should know about the relations, not the links themselves. If a relation isn't an IANA one, there should be a way to discover how to deal with it. It must know how to display and process the prev relation. If the client doesn't know about a relation, it just ignores it.
If people want to belittle something, either we aren't trying to solve the same problem (sure) or they're actively turning people away from what could be a serious advantage (more for me!)
If the cost of switching wasn't so high, I'd love to write Elixir all day. It's a joy.
You can have multiple small materialised views, which get updated when appropriate and are composed by a regular view. It’s more convenient than a single large materialised view.
The point is about a wider audience - I believe it is good to highlight people that have contributed significantly, yet overlooked by society at large - agreed about the CS sector, but then again on my intro to AI course less than 7% of bachelor students have heard of him in this context!
I dabble in SmallTalk for hobby stuff, and it actually seems to be the other way around these days: People find SmallTalk after becoming enamored with Ruby. That's definitely my story.
It's how I found SmallTalk back in the original pickaxe days, and Lisp, and Perl. Pretty serious expansion of consciousness compared to Basic, Pascal & C++.
reply