I'm not trying to be a dick, but it's pretty hilarious that we made these two posts at the exact same time [0]. I totally get what you're saying, but I don't understand the motivation behind it. A properly designed HTTP API is what Roy Fielding was discussing in his dissertation, but he was obviously talking about HTML pages full of hyperlinks. At the end of the day, does it really matter much if the definition is only 80% correct if the majority of the population understands the basic gist of the conversation?
If you can build the ultimate evolvable client, then you can collapse all UI into a single client.
Basically Roy Fielding told us to build an API that can only be operated by a human like intelligence, nobody could implement that because such an intelligence did not exist (hence the switch to imperfect HTTP APIs), and now that LLMs are a thing, said human like intelligence exists. This means Roy Fielding wasn't wrong, he was 25 years too early and ironically people should be building real REST APIs in the pendantic academic sense from today on and not the "pragmatic" HTTP API.
It's annoying, but that's been pretty common for the last decade. It's just like how everyone uses "REST" to mean "JSON RPC". In the end, we all basically know what the other ones are talking about, so it's pretty pointless to get bogged down in semantics.
It's common when talking about web services, where the kind of API is generally unambiguous. The problem here is we're discussing different kinds of APIs (shell commands, MCP, REST / JSON RPC) and so calling one of those kinds of APIs "API" is very confusing.
MCP is not strictly an API; it's a protocol shape (thus the "P" for Protocol) for delivering an API.
The API surface exists in the MCP payload.
Whereas application teams previously would have focused on APIs for external access, they now have to focus on MCP entry points (often to those same APIs, but with a different shape).
This is the worst moment in time to talk about "REST".
Do you mean the Roy Fielding "REST" or the HTTP API "REST"?
Calling the latter "REST" is wrong. It's like calling a hermit crab a snail.
Edit: I forgot to mention, the former is gaining relevance as the elusive evolvable clients are now a thing.
I'm not trying to be a dick, but it's pretty hilarious that we made these two posts at the exact same time [0]. I totally get what you're saying, but I don't understand the motivation behind it. A properly designed HTTP API is what Roy Fielding was discussing in his dissertation, but he was obviously talking about HTML pages full of hyperlinks. At the end of the day, does it really matter much if the definition is only 80% correct if the majority of the population understands the basic gist of the conversation?
[0] https://news.ycombinator.com/item?id=49908582
Unironically, Roy Fielding had a point.
If you can build the ultimate evolvable client, then you can collapse all UI into a single client.
Basically Roy Fielding told us to build an API that can only be operated by a human like intelligence, nobody could implement that because such an intelligence did not exist (hence the switch to imperfect HTTP APIs), and now that LLMs are a thing, said human like intelligence exists. This means Roy Fielding wasn't wrong, he was 25 years too early and ironically people should be building real REST APIs in the pendantic academic sense from today on and not the "pragmatic" HTTP API.
It's annoying, but that's been pretty common for the last decade. It's just like how everyone uses "REST" to mean "JSON RPC". In the end, we all basically know what the other ones are talking about, so it's pretty pointless to get bogged down in semantics.
It's common when talking about web services, where the kind of API is generally unambiguous. The problem here is we're discussing different kinds of APIs (shell commands, MCP, REST / JSON RPC) and so calling one of those kinds of APIs "API" is very confusing.
"REST" is one of many way to implement APIs.
Exactly. It's confusing to talk about MCP vs API when "API" describes the whole class of possible values, of which "MCP" is one of them.
MCP is not strictly an API; it's a protocol shape (thus the "P" for Protocol) for delivering an API.
The API surface exists in the MCP payload.
Whereas application teams previously would have focused on APIs for external access, they now have to focus on MCP entry points (often to those same APIs, but with a different shape).
Seems like in this context API means HTTP API lol