Re: A broader discussion: the usefulness of REST

I think the chief problem for REST is that you can't sell it. GraphQL, for
instance, tries to address similar problems (IMO), but it exists as a
product in many ways. REST is a set of practices that are hard to "bundle
up" into something you can just use.

On the other hand, Hydra is a codification of a lot of those practices -
well defined ways of saying "this is a link" in machine-readable APIs.
That's very useful because it answers a big chunk of questions that you
have when you start to use REST in that context. You still have a big part
of the problem left to solve, but that's also context-bound to your API
and application.

What I don't think is that the Hydra CG is a forum for the debate of REST
being useful or not. If you think it's not, that's fine, but that doesn't
contribute to the broad discussion in this CG, or in JSON-LD either iMO.

On Wed, May 21, 2025 at 1:58 AM Pierre Thierry <pierre@nothos.net> wrote:

> Hi everyone,
>
> I'd like to start a couple of discussions here, some directly about
> Hydra but others more broadly about REST, to have a better common
> understanding of the problems we aim to provide solutions for.
>
> This is one of those broader questions: why REST APIs?
>
> One person already made a comment here that I've seen countless times
> since I started communicating on REST: it doesn't solve a problem that
> people actually have. I feel that this is a tautological rationalization
> after the fact, to be honest.
>
> First, it's more an argument from intuition than anything, but after
> creating software for around 30 years, I am at this stage where it's
> finally obvious that coupling that is tighter than strictly necessary is
> a huge bane of software development and operations. In that sense, as
> REST offers concrete ways to loosen the coupling between clients and
> servers, I cannot see how it could not make things better.
>
> On a more factual level, we see all the time the inertia around API
> evolution. It has almost become a fact of life that evolving an API is a
> huge PITA and a source of frustration both for those that deploy the API
> on the server side and for those operating clients. It's not that people
> would not like smooth transitions and painless gradual migrations. It's
> that it's seen as something impossible, and without REST, I think we
> have gathered solid evidence that it basically is.
>
> So when I explain to people how we could implement smooth API migrations
> with REST, I have seen several times the answer "nobody needs that". I
> think the honest answer should be "wait, we thought it was impossible,
> we stopped considering this an option".
>
> In this current situation, I feel like a comprehensive set of use cases
> of REST would really benefit Hydra. I feel like the ideal would be if we
> had an actual implementation of most of those use cases, including
> servers and client showcasing the ability to evolve their API
> dynamically, to show how far the flexibility of REST could go (in
> realistic use cases, but I'm pretty sure we'll find plenty of those).
>
> A couple of months earlier, I wrote a small article outlining reasons I
> see to use REST in APIs:
>
> https://gist.github.com/kephas/826d4c90222162a2bec0be4971d5da9c
>
> I'm still eager to get comments on this article.
>
> Do people here agree that publishing something like this would be
> useful? Could this article be a good starting point or should we start
> the discussion from scratch?
>
> Curiously,
> Pierre Thierry
>
>