[hobofan]

> Had we stuck with REST for the last 20 years we'd be way ahead on that front

We are where we are because there (sadly) hasn't been a reasonable business case to advance REST API documentation beyond the point of badly-documented OpenAPI schemas where the main utility is in generating type-safe API wrappers across different programming languages.

With MCP, there is at least a name to a new movement to build self-describing APIs, as with the advent of LLMs there is now enough of a utility for it. All other pushes into that direction have died out ~10 years ago.

[_heimdall]

Correct me if I'm wrong, but I thought OpenAPI was itself an attempt to wedge REST concepts back on top of mostly RPC-based APIs. I.e. add documentation and a standard set of schemas on top of JSON APIs (mostly).

I do think the problem is from business concerns, though, and are a clear predictor that MCP will fail. Coming out of the dotcom bubble those left standing wanted to build moats and walls, not APIs that any third party could easily discover and use. The need for REST only shows up when a new player makes a move to effectively gobble up the role of being the gate keeper to the internet. With scale other companies will follow, but begrudgingly and only for a short while.

[wild_egg]

Sadly not. One of the constraints of REST is that the API be completely self-descriptive. If you need out-of-band information like an API spec, then it's basically not RESTful by definition.

I'm using a REST API to read your comment and submit my response — I didn't need to reference external HN API docs. The interface here is fully self-describing.

[_heimdall]

I agree, but don't quite follow how your comment fits in here.

In a REST approach, I'd expect an LLM to need some kind of initial entry point, much like needing the initial URL for the HN home page. From there the LLM should be able to parse and discover possible actions, call those actions, and understand the response only by parsing the results and any schemas provided.

[wild_egg]

To be honest, I think I meant to put that reply on a different comment.

In any case, we're on the same page about REST. OpenAPI was mentioned though and I don't think that's ever actually compatible with that type of usage.

I don't think I've ever encountered an API following OpenAPI that was completely self describing and could be discovered and navigated from a single entry URL. They're always paired with some swagger docs or other external content. That instantly makes them not RESTful.

But you're totally right that my comment didn't fit. Might have meant it for the grandparent comment? Not sure.