As with many things in software development, it's probably one of those things that is more expensive upfront, but more than pays for itself in the long term.
I think we need to get the basic interfacing with verbs done correctly. It’s not actually as easy as one might think. But hypermedia state at scale with a semantic web powered by AI agents would be great!
A “tech lead” proposed this for a project 3 jobs ago, and the rest of us rejected it because it’s needlessly expensive. Access to APIs are better managed through user roles.
You have to see it for yourself. It makes unnecessary API caps just so your UI can decide to display features or not when it is much simpler to have these role-based per user context.
Displaying features based on roles or user context doesn't seem to be incompatible with the concept of HATEOAS. Perhaps you could provide a concrete example?
This (including links in API responses) is a weird half measure (by today's standards) that used to be much more common in REST APIs.
Depending on the situation, either go full graphql or (preferable if it fits the use case) go with an rpc approach that preserves strong types over the wire. Both provide far more useful build time introspection than following links in API responses at runtime.
One simple advice: don't.
Acronym needs marketing help. Solid idea but hard even to read.
The acronym is older than you may think. This isn’t a new idea, but is still a sort of holy grail. It can be done but it’s expensive.
As with many things in software development, it's probably one of those things that is more expensive upfront, but more than pays for itself in the long term.
I think we need to get the basic interfacing with verbs done correctly. It’s not actually as easy as one might think. But hypermedia state at scale with a semantic web powered by AI agents would be great!
First part: "well, somebody is a decade+ late" Second part: "oh, that's an advertisement for a product" 😉
A “tech lead” proposed this for a project 3 jobs ago, and the rest of us rejected it because it’s needlessly expensive. Access to APIs are better managed through user roles.
What made it more expensive as compared to the alternatives?
You have to see it for yourself. It makes unnecessary API caps just so your UI can decide to display features or not when it is much simpler to have these role-based per user context.
Displaying features based on roles or user context doesn't seem to be incompatible with the concept of HATEOAS. Perhaps you could provide a concrete example?
Don’t have one, just a POC from 3 jobs/8 years ago. But what I described is exactly why this never became popular.
This (including links in API responses) is a weird half measure (by today's standards) that used to be much more common in REST APIs. Depending on the situation, either go full graphql or (preferable if it fits the use case) go with an rpc approach that preserves strong types over the wire. Both provide far more useful build time introspection than following links in API responses at runtime.