Re: HATEOAS on demand

True. By the same measure, apidocs are out of band BUT we read them when
building our interface/application.

and thats where you find out not only the header but also:
- the roles that have access to the endpoint (RBAC)
- params to be sent with the request/response for said ROLE (ABAC)

If HATEOAS is not a replacement for api docs, then this makes perfect sense
not to have it be a DEFAULT when sending a request.

Making HATEOAS the default makes it so you send 5kb of data when the client
only requested 1kb.
That adds up with every concurrent request.

If this is not an acceptable, people need to fix HATEOAS so it's not a
default (or hardcoded)



Owen Rubel
orubel@gmail.com


On Tue, Jan 14, 2025 at 4:12 PM Rahul Gupta <cxres@protonmail.com> wrote:

> To receive links, your clients will have to know about the
> X-LINK_RELATIONS from the documentation. That's out of band information
> that a client needs to have prior knowledge about, your API is no longer
> Hypermedia driven. The purpose of REST constraints (incl. HATEOAS) is to
> allow clients and servers to evolve independently while preserving interop.
> This matters when designing APIs for internet timescales, i.e. that could
> potentially exist for decades.
>
> Having said that, if you control both client and server software, the API's
> do not have to be REST.
>
> BR/Rahul
>
> On Wednesday, January 15th, 2025 at 4:11 AM, Owen Rubel <orubel@gmail.com>
> wrote:
>
> Not sure if this is the right place to send but wanted to discuss my
> hatred for HATEOAS because it sends so much additional and unwanted
> information with every request/response.
>
> So in my spring-boot plugin I solved this by auto-generating (via
> recursive lookup) only when a specific header is sent (
> https://beapi-io.github.io/beapi-docs/0.9/advanced.html#section-6)
>
> That way if you WANT the link relations, you can get them on demand.
>
> But endpoints do not default to that.
>
> Best of both worlds. Thoughts?
>
> Owen Rubel
> orubel@gmail.com
>
>
>