Monday, April 20, 1998 at 12:33:14 PM PacificBob Atkinson on RPC over HTTP-POST
Bob Atkinson is a lead developer in the DCOM group at Microsoft. His message is in response to An Interesting Quandary, 4/17/98.Bob Atkinson on RPC over HTTP-POST
The debate is a red herring. The way that POST is used in practice today with respect to form processing on Web sites of pretty much any sophistication at all is completely and totally 100% isomorphic to a procedure call.
With RPC over HTTP-POST we will not add to or take away from existing semantic expressiveness. RPC POSTs are no different than what is already on the web today; the words in the content are just spelled differently.
An important distinction we have from existing RPCs like DCE RPC is that in using HTTP we're intrinsically higher up the protocol stack. This is significant wrt firewalls. For example: if you want to make DCE RPC work through a firewall, then in practice you have to deal with at least:
- the fact that there's no 'proxy' mechanism, so you have to let raw UDP and TCP ports right through
- the fact that even those ports are not a fixed set, but dynamically allocated.
By sitting above HTTP, we have crucial advantages vs DCE RPC, among them the existence of high level proxies that connect across the wall way above the TCP layer. In RPC-over-HTTP, no TCP or UDP connection ever goes straight through the firewall.
The real issue to be concerned about is not one of semantic power, it's one of how low down the protocol stack you have to let things through in order to make the system work. The higher up you can raise this bar, the more secure the firewall is. Yes, there are sys admins that don't grok this. Even a whole bunch of software developers, especially in my neck of the woods :-(. But it's the truth.
Adding another verb only complicates and confuses the situation, and runs from the real issue. We should stick with simply POST.
John Tigue
I agree with Bob a new HTTP verb, say, INVOKE has little technical value. I view POSTed XML messages to software components as simply an evolution of HTML forms and CGI.
We are essentially simply structuring the interfaces and serialized method messages which will promote interoperability. The only technical benefit I see in the INVOKE verb is that it may allow performance tweaking by firewall software. With RPC messages distinguished by the INVOKE verb, preferential treatment can be given to RPC calls or to HTML forms. RPC calls may be more important to business critical applications.
Or quickly servicing human customers interacting with forms may be more important. As Bob points out that by itself does not warrant the political overhead of standards body work.
Nonetheless I do promote the idea of INVOKE. The real benefit of INVOKE is social not technical. I mention INVOKE in my presentations. I simply see it as a pacifier which allows me to circumvent this type of discussion during my limited presentation time.
This page was last built on 4/21/98; 11:20:55 AM by Dave Winer. dave@scripting.com