(no title)
keithwhor | 11 months ago
What I realized was that these specs are valuable because they’re stable over long periods of time and handle many sorts of edge cases. Also from a systems integration perspective, everybody already knows and is trained in them. Over many years I accepted the wisdom of commons.
A lot of tooling already exists to make development of these sorts of systems easy to implement and debug. Hence why I think for Remote MCP servers, HTTP as it exists is a great choice.
mattmanser|11 months ago
For a long time lots of servers didn't really support PUT or DELETE, and it was only the early 2010s that it became common.
It's still a problem sometimes that you have to explicitly enable them (I'm looking at you IIS + WebDAV).
PATCH wasn't even added till 2010 and you still don't see it commonly used.
Perhaps we have different understandings of 'stable' and 'many years'.
I also agree with you on RPC, it's pretty ridiculous that some guys tried to boil every single API down to essentially 4 verbs. I remember when Google went all crazy on implementing pure REST and their APIs were atrocious.
And everyone still goes along with it even though it clearly doesn't work, so you always end up with a mix of REST and RPC in any non-trivial API.
But pure RPC doesn't really work as then you have to change every call to a POST, as you mention. Which is also confusing as everyone is now used to using the really restricted REST CRUD interface.
So now pure REST sucks and pure RPC sucks. Great job HTTP standards team!
To be fair to them, I know it's hard and at some point you can't fix your mistakes. These days I guess I've just accepted that almost all standards are going to suck a bit.