> I am leaning towards using HTTP. RPC doesn't seem like it would be a good idea in 2016. Quite the contrary. RPC is an excellent idea in 2016, if you're willi

> I am leaning towards using HTTP. RPC doesn't seem like it would be a good idea in 2016. Quite the contrary. RPC is an excellent idea in 2016, if you're willing to forego "trendiness". It gives you pretty much the same as you're getting from what people today call "REST API", but already has defined how to report call results and errors and doesn't require you to juggle with API endpoint URLs, so it's a win in pretty much every field. > I would then have to expose a RPC service to the world. Yet you don't seem concerned with exposing the same thing with the same operations with HTTP. > I don't have any background in deploying an RPC service, but I do know how to deploy and secure a HTTP service to the world. Use some HTTP-based RPC protocol, then. Little difference, really.