[_heimdall]

Very cool! The docs here are a great overview of how MCP works, and a reminder to me of an old lesson:

We never should have abandoned REST. The whole point was for an interface to be self-describing; we wouldn't need MCP (or Swagger, or OpenAPI, etc) if we just stuck to REST instead of diverting down the JSON RPC route we've been on for 20 years.

[_verandaguy]

Wait, who's abandoned REST?

And in what way is OpenAPI an abandonment of REST? It's an API documentation system that can be leveraged for generating REST server boilerplate code. If anything, it builds up the quality-of-life around REST.

[_heimdall]

I haven't seen a REST API in production for many years, maybe 15?

That's anecdotal obviously, but almost every, if not every, API I use today is an RPC call returning JSON.

Edit: to be clear, the distinction between what REST was defined as and what we use today often doesn't really matter. We use JSON APIs today, it is what it is. This is a case where it really matters though, LLM companies are now trying to push an entirely new protocol that tries to do roughly what REST did in the first place.

[mcdow]

So the things we call "REST" in 2025 are not quite the same as the original specification of REST. One key aspect that has been abandoned is that sent data should be self-describing. That is, it shouldn't require any additional information to be useful. i.e. API documentation for JSON endpoints.

There's a great chapter on this in Hypermedia Systems[1]. Talks about both this and HATEOAS(Hypermedia as the engine of application state).

1. https://hypermedia.systems/components-of-a-hypermedia-system...

[0x445442]

By REST you mean HATEOAS?

[_heimdall]

That's one constraint of REST, yes.

[wild_egg]

You can't have REST without it