On Tue, Mar 27, 2018 at 7:34 AM, Rob Berendt <rob@xxxxxxxxx> wrote:
I plead ignorance on remote procedure calls. Web Services may be a fun
learning experience and something to add to the tool box but I'd have to
have a lot more information to justify going down that road.
I'm no expert myself, but my dabbling with RPC and Web services in
Python gives me the impression that, from 20,000 feet, both are about
the same. Actually, both of those terms are relatively broad and each
encompasses at least a few distinct specific implementations. The
Python RPC I've played with uses HTTP as its transport protocol, and
as such I believe the low-level plumbing is the same as for Web
services.
On the calling (i.e. client) end, RPC and Web services really might as
well be the same thing. At most, there are some easily papered-over
syntax differences.
On the serving end, I am guessing the difficulty in setting things up
depends almost entirely on what package(s) you are using. I guess in
some cases these would be called "frameworks". In the extreme DIY case
(very lean or no framework), I guess you'd have to write your own code
to create and interact with sockets. In the extreme
someone-else-has-already-done-it-for-you case, you basically just
write application-level code on the server as you normally would, and
then "register" that code as remote-callable. The framework handles
everything else.
Python already has surprisingly easy-to-use RPC support built into its
standard library. You can do the hello-world examples verbatim from
the documentation in minutes and it Just Works. But you have to have
Python on both ends. The great advantage of Web services, as hinted at
by others, is that they can be consumed by any client language, on any
client platform.
John Y.
midrange.com
