I think there are some standards fans whipping out the downvotes, but I think jerf and I are both very aware that this is not how it SHOULD be. But it is how it is. I built an API scraper years ago now, and I gave up, APIs are not standardized, they're not consistent. I dreamed of an interoperable library of APIs you could pipe around to create new applications. It's too much work to manage all the differences in how people have built their APIs. But as jerf pointed out, there can be myriad reasons standards end up playing second fiddle.
I think the HTTP standard should be a bit less detailed than it tries and fails to be, but I do think at least OK, Not Found, Unauthorized, and a couple of others are good. Basic proxy control also would be good in general, although those should be moved into headers. (Which they partially are. But I think they should maybe be moved all the way instead of being spread out the way they are. This is, of course, in some hypothetical perfect world where I can just rewrite the standards without having to worry about any existing code, which is not the world either I or the current standards authors live in.)
But if you sit down and look at the RFC, and really try to understand what quite a lot of the codes are, they're just useless. Not necessarily to everyone, but they're useless to me, because many of them clearly involve some sort of not-universally-shared context and probably mean something very, very precise to somebody, but not me, not my API users, not the writers of the APIs I consume, etc.
Plus, you know, ultimately those codes were for documents, not for APIs anyhow, and that shows too, in some basic missing stuff for API calls.
I'd love it if this wasn't the case, absolutely. But it is, and yelling at people to "conform to this RFC harder" is just a waste of time on multiple levels.
