Classic RPC allows the client to use remote code as though it were local code.
// client codeApi.DoSomething();
Theoretically, the client does not need to know whether the code runs locally or the request is transmitted and executed on the server. Although it may be unwise to actually ignore that consideration.
Thanks Kasey. So say I wrap a simple HTTP request library to hit an API somewher, so that it looks like I'm just running local functions or methods in my program, does that count as an RPC?
It could be. Traditionally, RPC means that when I call a procedure on the client, it is a stand-in for the same method on a remote machine. When I call Api.Something() on the client, then Something() is to be called on the server. (I should have made that more clear in my original answer.) HTTP could be used as the transport mechanism, but (unlike REST) that is not emphasized.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Classic RPC allows the client to use remote code as though it were local code.
Theoretically, the client does not need to know whether the code runs locally or the request is transmitted and executed on the server. Although it may be unwise to actually ignore that consideration.
Thanks Kasey. So say I wrap a simple HTTP request library to hit an API somewher, so that it looks like I'm just running local functions or methods in my program, does that count as an RPC?
It could be. Traditionally, RPC means that when I call a procedure on the client, it is a stand-in for the same method on a remote machine. When I call
Api.Something()on the client, thenSomething()is to be called on the server. (I should have made that more clear in my original answer.) HTTP could be used as the transport mechanism, but (unlike REST) that is not emphasized.