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 fina

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.