HTTP is not RPC

2011-08-12 @ 12:16#

i had an interesting set of twitter convos in the last 24 hours centered around HTTP, RPC, and REST. i especially enjoyed my interactions w/ @wmartinez, @dilipkrish and @AndrewWahbe.

essentially, the convo gravitated toward the comparision of Fielding's REST to common RPC when implementing solutions over HTTP. along the way, (after a couple mis-steps called out by @dilipkrish) i said that i find it very interesting that RPC over HTTP is so popular/common when the two are so 'dissonant' to each other.

@AndrewWahbe chimed in that, essentially HTTP is RPC (just a very simple set of calls) and i disagreed. i posted a link to this quote from Fielding's dissertation which i have always found intriguing:

What distinguishes HTTP from RPC isn't the syntax. It isn't even the different characteristics gained from using a stream as a parameter, though that helps to explain why existing RPC mechanisms were not usable for the Web. What makes HTTP significantly different from RPC is that the requests are directed to resources using a generic interface with standard semantics that can be interpreted by intermediaries almost as well as by the machines that originate services. The result is an application that allows for layers of transformation and indirection that are independent of the information origin, which is very useful for an Internet-scale, multi-organization, anarchically scalable information system. RPC mechanisms, in contrast, are defined in terms of language APIs, not network-based applications.

Fielding's dissertation, Section 6.5.2 - HTTP is not RPC

for me, one big 'take-away' from this quote is the last line: "RPC mechanisms ... are defined in terms of language APIs, not network-based applications." (emphasis mine)

to me, this cuts to the heart of the subject: language-focused vs. network-focused. most devs today are operating on a language-focused paradigm ("I write C#|Java|Erlang|Javascript|etc. apps."). relatively few devs operate on a network-focused paradigm ("I write network apps."). and this is supported in the way frameworks and libraries are created and marketed today. most of them are focused on a platform and/or language model and most of them go out of their way to 'hide' the distributed network aspects of Web programming.

BTW - at the start of most of my presentations, i tell my audience that one way in which i describe myself and my job is the following:

"I program the Internet."

this POV has lead me, over the years, to change platforms, languages, arch models, etc. (sometimes in concert, sometimes piece-meal) based on the project at hand and the resource avaiable. it's the distributed network that has my attention, not the tools. i'll do whatever it takes to get the job done as best i can because...

"I program the Internet."

how about you?

HTTP