The words are all messed up at this point, but RPC traditionally meant mechanisms like “procedure naming” and “marshal arguments and return values”. It’s designed to make remote procedure calls as convenient as local ones with respect to particular programming languages.
So I’d say HTTP isn’t RPC because it’s not designed for, or convenient for, that purpose.
You can make it do such things, but it takes extra work, and you also lose things like HTTP proxy support (middleboxes).
If HTTP were RPC, then you wouldn’t have additional protocols like JSON-RPC tunneled inside HTTP. JSON-RPC specifies how your arguments and return values are marshaled.
If HTTP were RPC, you wouldn’t have to say “HTTP POST”. Middleboxes understand HTTP verbs; they often don’t understand your custom protocol inside HTTP. The network isn’t just about the end points.
Likewise, TCP/IP isn’t a protocol for hypertext, although you can use it that way. You have another layer with more semantics.
I suppose the idea of “HTTP is RPC” takes a minimalist definition of both terms-- RPC as in “it invokes procedures remotely”, and HTTP as in “a well-supported presentation layer”.
I get the reluctance but I still think it’s somewhat semantic from the server’s perspective:
HTTP verbs are cache controls, which is not unusual for RPCs (otherwise would be done in request metadata/headers/etc)-- middleboxes are generally aligned with this.
HTTP endpoints (or “resources”) are encoded procedure names
To me, HTTP is a somewhat specialized kind of RPC (with specified caching and method encoding). We can of course build other kinds of RPCs on top of any RPC too.
We can draw the line elsewhere, but at the very least HTTP is very close to being an RPC. :)
In that HTTP is all about manipulating a large set of resources (nouns) with a very small set of fixed commands (verbs), and there are no remote procedures at a conceptual level at all.
Right. As I mentioned in a sibling comment, I think I’m using a weaker definition of RPC than what you’re describing here. For me — and I think for most developers in this day and age — RPC is anything which is synchronous and follows request-response semantics. By this definition, all HTTP operations qualify. I understand this is not the original meaning.
In what way is HTTP — or, at least, HTTP POST — not RPC?
REST certainly isn’t RPC, sure, but REST is an abstraction layer above HTTP.
score 6 · canonical
The words are all messed up at this point, but RPC traditionally meant mechanisms like “procedure naming” and “marshal arguments and return values”. It’s designed to make remote procedure calls as convenient as local ones with respect to particular programming languages.
So I’d say HTTP isn’t RPC because it’s not designed for, or convenient for, that purpose.
You can make it do such things, but it takes extra work, and you also lose things like HTTP proxy support (middleboxes).
If HTTP were RPC, then you wouldn’t have additional protocols like JSON-RPC tunneled inside HTTP. JSON-RPC specifies how your arguments and return values are marshaled.
If HTTP were RPC, you wouldn’t have to say “HTTP POST”. Middleboxes understand HTTP verbs; they often don’t understand your custom protocol inside HTTP. The network isn’t just about the end points.
Likewise, TCP/IP isn’t a protocol for hypertext, although you can use it that way. You have another layer with more semantics.
score 38 · canonical
Ah, okay, I’m definitely using a weaker definition of RPC than what you’re describing here.
score 7 · canonical
I suppose the idea of “HTTP is RPC” takes a minimalist definition of both terms-- RPC as in “it invokes procedures remotely”, and HTTP as in “a well-supported presentation layer”.
score 2 · canonical
I get the reluctance but I still think it’s somewhat semantic from the server’s perspective:
To me, HTTP is a somewhat specialized kind of RPC (with specified caching and method encoding). We can of course build other kinds of RPCs on top of any RPC too.
We can draw the line elsewhere, but at the very least HTTP is very close to being an RPC. :)
score 2 · canonical
In that HTTP is all about manipulating a large set of resources (nouns) with a very small set of fixed commands (verbs), and there are no remote procedures at a conceptual level at all.
score 1 · canonical
Right. As I mentioned in a sibling comment, I think I’m using a weaker definition of RPC than what you’re describing here. For me — and I think for most developers in this day and age — RPC is anything which is synchronous and follows request-response semantics. By this definition, all HTTP operations qualify. I understand this is not the original meaning.
score 2 · canonical
Fair enough. Thanks for the qualification and clarification 👍
score 2 · canonical
Agreed. HTTP is definitely an RPC system. It even has verbs!
score 2 · canonical
I mean Whois is definitely an RPC system: it has a verb! Sure, it’s implicit, but still!
score 4 · canonical
I think you need to allow arbitrary verbs to be RPC :P
score 1 · canonical