3 ms·
Why not going simply with a proper RPC protocol? You're going to do it this way anyway, except you'll strangle yourself with a mess of URLs and request routers
by dozzie 10y ago
Why not going simply with a proper RPC protocol? You're going to do it this
way anyway, except you'll strangle yourself with a mess of URLs and request
routers and ORMs and whatnot, but without well-defined protocol with sane and
consistent error reporting.
- ryanmccullagh 10y agoI am leaning towards using HTTP. RPC doesn't seem like it would be a good idea in 2016. I would then have to expose a RPC service to the world. 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. Is RPC really used anymore?
- dozzie 10y ago> 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.