[genmud]

> The thing with REST, is that at its core, it's basically a RPC (Remote Procedure Call) that we've been trying to cram in the HTTP protocol. There is no good reason to do that. HTTP wasn't made for this, and we should instead be abstracting that layer away instead of trying to use it for purposes it's not meant to fulfill.

Yea, I'm gonna have to disagree with that statement. Things like OpenAPI have tried to solve the problem of having a generic format, but the problem is that in practice, apps/services are opinionated on how they structure data. For some this is a really good thing™, for example when an engineering group really thinks about their API design while for others, who haven't thought it through, this becomes a living nightmare for users of those APIs.

HTTP/REST are used (and will continue to be used) because they are ubiquitous. I would argue that 99.99999% of internet devices have the capability to speak REST. Whether that is curl in a shell script, javascript in a browser or python in an application... Nearly everything is capable of speaking REST, which I would actually argue is why a well thought out REST endpoint is a great solution for most applications.

There are "true" RPCs that do RPC really well/fast and when it makes sense to leverage those in your architecture you absolutely should. However, if it requires other developers to integrate with it, REST APIs are typically the way to go.