[flexblue]

As other have noted, someone caught on to the simplicity of RPC.

It always baffled me how so-called RESTful APIs became popular, despite virtually all of them being RPC APIs with a veneer of rather pointless HTTP semantics.

Virtually none of those APIs do anything to serve the intentions and goals behind REST[1]. Furthermore, many RESTful APIs end up being wrapped into language-specific clients anyway, because they have poor ergonomics in their raw state.

I consider RESTful APIs the most significant anti-pattern not widely recognized as such.

[1] https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...

[tasubotadas]

> the simplicity of RPC

Simplicity? Have you ever tried to integrate distributed applications that do not share the same codebase?

And calling REST anti-pattern tells me that you aren't that familiar with alternatives.

>despite virtually all of them being RPC APIs with a veneer of rather pointless HTTP semantics.

If you want to do RPC over HTTP and pretend that it is REST interface, it isn't really a problem of REST.

[brillout]

So true.

That said, for an API consumed by third-party developers, REST makes a lot of sense. Otherwise, which is like 98% of the APIs out there, RPC really is superior.

I've implemented a tool similar to what OP is building: Wildcard API [1]

> rather pointless HTTP semantics.

Agree. Actually, while implementing Wildcard API, I made sure to abstract away all HTTP semantics. With Wildcard, you don't think in terms of "HTTP verbs" but you think in terms of functions. Like you are naturally used to.

> It always baffled me how so-called RESTful APIs became popular

I believe REST became popular because it got lot's of exposure since all third-party APIs were using REST.

[1]: https://github.com/reframejs/wildcard-api