[iofiiiiiiiii]

My preferred API design is RPC - expose various method calls to other systems. In practice, this means gRPC whenever possible, basic HTTP RPC when not, and finally SOAP is also fine if you are on a platform that has a sane implementation.

I could try think of why but in practice, it just seems to work out the best. Are there reasons? Sure. But coming up with a detailed rationale would take some days of thinking. It just works very well.

This means on my service side I expose SaveWidget(id, body) ReadWidget(id) PatchWidget(id, changes) QueryForWidgetsByFoo(foo) QueryForWidgetsByFooBarAndSomeOtherSTuff(foo, bar, otherstuff) and on the client side I just call them as if they were local (but rather slow performing) functions.

Lots of little ifs and buts but this has proven the superior approach in all scenarios where I control both client and server. I might go for REST for wide-audience APIs just for the recognizability.

[palberg7]

Agree and that's exactly what I want to do. I want to define and call functions as if they were local. I control both client and server.

For Node.js there is https://github.com/reframejs/wildcard-api