Re: HATEOAS on demand

> And if being done dynamically, you may as well have it on demand.

As a counterpoint to this. Remember that any code you write is code you've
got to maintain. It's not free.

Yes, there are cases where you're generating hypermedia links dynamically.
But not all the time. Often the links will be relatively static. (Self
links or pagination links, for example)

And even if you are doing it dynamically, adding extra code in to check an
extra condition to determine if you're going to generate them or not is
extra code to write, test, maintain, etc.

Conversely though, the additional payload size from these hypermedia links
probably isn't huge, probably does compress well under gzip if needed, and
clients that choose not to use them can easily just ignore them in the
responses. And always generating them just reduces the complexity of your
server a bit.

There's also the fact that, if you're going to write the code to generate
these links, you likely want clients to make use of them. Putting them
behind an extra gate just makes it more likely that clients won't bother
using them, which leads to even more code that you're maintaining that
isn't getting used.

Just my 2p :)

Cheers

On Wed, 15 Jan 2025 at 15:46, Owen Rubel <orubel@gmail.com> wrote:

> Well thats the issue.
>
> A link can be accessed by different ROLES; an ADMIN ROLE can access the
> same endpoint as a USER ROLE but require sending and receiving entirely
> different data (see RBAC/ABAC)
>
> Thus hardcoding is NOT a solution for secure endpoints. They have to be
> created dynamically to take this into consideration.
>
> And if being done dynamically, you may as well have it on demand.
>
> Owen Rubel
> orubel@gmail.com
>
>
> On Wed, Jan 15, 2025 at 1:52 AM Asbjørn Ulsberg <asbjorn@ulsberg.no>
> wrote:
>
>> On 15 Jan 2025, at 03:20, Owen Rubel <orubel@gmail.com> wrote:
>>
>> > so basically what I am saying is that since you hardcode the links for
>> HATEOAS, they violate security like RBAC which defines what ROLES can
>> access which endpoints.
>>
>> If you consider the existence and visibility of a particular link in a
>> response message a security risk (although that sounds a bit like security
>> by obscurity to me), or performance overhead, then just exclude the link
>> from the response.
>>
>> The response can be tailored to each authorised client based on RBAC,
>> ABAC and any other configuration the origin server may consider applicable
>> to the given request.
>>
>> --
>> Asbjørn Ulsberg.         -=|=-         asbjorn@ulsberg.no
>> «He's a loathsome offensive brute, yet I can't look away»
>
>