Dave Winer has a blog post where he responds to a post entitled SOAP, REST and XML-RPC by Randy Charles Morin. He writes

I wonder if it's be possible for me to disagree with Randy Morin without getting flamed. I never said XML-RPC is better than SOAP or REST, or more perfect or pure, or better documented. I don't care if the others have better websites, or more advocates posting on mail lists. The reason I advise would-be platform developers to support XML-RPC is because at least for some developers (including me) it's so much faster to implement, so we spend less time creating glue and get to building applications sooner. I've learned that the sooner developers get to the fun part, the more likely they are to deploy. And if that's the goal, why not support it? BTW, I never said they shouldn't support SOAP or REST, in fact I often provide multiple interfaces to my would-be platforms, because I've learned that if you want uptake for new ideas, you shouldn't argue over small things like this, you should say yes whenever you can.

I agree 100% with Dave Winer. If you are building a service on the Web, then you shouldn't discriminate against any platform, application or device. This means you can't pick one approach or one technology for building your service because different platforms have different levels of support for various approaches. A developer using Visual Studio will find using SOAP easier then REST or XML-RPC while on the flip side a developer using Python or Perl is likely more at home dealing with XML-RPC than using SOAP. Choosing one technology over the other is choosing to discriminate against one platform or set of developers over the other.

In some cases this is necessary to keep maintenance costs down by supporting a small set of protocols but in general if you are building a service on the Web, you want it to be inclusive not exclusive. Arguments of technological superiority be damned.


 

Categories: XML Web Services
Tracked by:
http://scripting.wordpress.com/2006/07/05/scripting-news-for-752006/ [Pingback]
http://www.gazitt.com/Blog/PermaLink,guid,d989e1c7-912f-4df3-b820-8e7a168bcefd.a... [Pingback]
/blogs/wcf_team_bloggers/archive/2006/07/06/4054.aspx [Pingback]
"Down with Protocol Dogmas" (OhmBlog) [Trackback]
http://www.gazitt.com/Blog/PermaLink,guid,c46080ed-c2dd-4e8b-ba2f-207d909a7aa1.a... [Pingback]
/blogs/wcf_team_bloggers/archive/2006/07/06/Down-with-Protocol-Dogmas.aspx [Pingback]
http://silauma.info/scarolina/sitemap1.html [Pingback]
http://zabivwn.net/california/sitemap1.html [Pingback]
http://fwmwly7.net/arizona/sitemap1.html [Pingback]
http://fwmwly7.net/alaska/sitemap1.html [Pingback]
http://weujmru.net/musicians/sitemap1.html [Pingback]
http://weujmru.net/sublets/sitemap1.html [Pingback]
http://issl7ti.net/lottery/sitemap1.html [Pingback]
http://restablog.com/household/sitemap1.html [Pingback]
http://kivablog.com/sitemap1.html [Pingback]
http://lvxjtu6.net/video/sitemap1.html [Pingback]
http://www.freewebtown.com/randevy [Pingback]
http://box405.bluehost.com/~dugablog/sitemap1.html [Pingback]
http://lf0s3on.net/community/sitemap1.html [Pingback]
http://ayavqoc.net/sitemap1.html [Pingback]
http://kiva.startlogic.com/sitemap1.html [Pingback]
http://anubis.sslcatacombnetworking.com/~rocata/phones/sitemap1.html [Pingback]
http://host239.hostmonster.com/~blogford/sitemap2.html [Pingback]
http://host239.hostmonster.com/~blogford/sitemap4.html [Pingback]
http://gator413.hostgator.com/~digital/music/sitemap1.html [Pingback]
http://fastblog.sc101.info/auction/sitemap1.html [Pingback]
http://umatutman.com/housing/sitemap1.html [Pingback]
http://umatutman.com/musicians/sitemap1.html [Pingback]
http://mi9bxxt.net/sitemap1.html [Pingback]
http://fastestblog.net/sitemap1.html [Pingback]
http://kmnjey0.net/college/sitemap1.html [Pingback]
http://ik6bcb7.net/sitemap1.html [Pingback]
http://box432.bluehost.com/~zbloginf/sitemap1.html [Pingback]
http://d579737.u108.floridaserver.com/sitemap2.html [Pingback]
http://gator442.hostgator.com/~hockteam/ipod/sitemap1.html [Pingback]
http://gator442.hostgator.com/~hockteam/alaska/sitemap1.html [Pingback]

Wednesday, July 5, 2006 7:53:39 PM (GMT Daylight Time, UTC+01:00)
Inclusivity, sure. But just because people have historically used a particular technology enough justification for artificially keeping that approach alive?

Regarding protocols, if you are building a service on the Web, surely it's good practice to at least favour those that are Web-friendly? Reasonably well-designed? The tunnelled RPC approach isn't particularly Web friendly, because it's closed to any system without the (usually unnecessary) packaging layer.

Personally I think XML-RPC should be strongly deprecated for technical reasons. Error reporting is haphazard to say the least, internationalization is broken because it doesn't understand timezones. Like Randy said, XPath/XQuery stuff is a non-starter. Ok, to support existing blog tools then you're don't have much choice other than to support the Blogger API and/or the MetaWeblog API. But when you have a choice, do you really want to support such pain?

In the same way there's no compelling reason for anyone to support RFC 822 dates when RFC 3339 is available and technically superior, there's no good reason to support tunnelling protocols when direct HTTP methods are available on more platforms than XML-RPC.

btw, Dave said not long ago: "One way to do something, no matter how flawed that way is, is better than two, no matter how much better the second way is." Doing inter-system comms is presumably then an exception (unless the One Way is Dave's way).
Wednesday, July 5, 2006 10:46:45 PM (GMT Daylight Time, UTC+01:00)
Same bias towards XML-RPC is evident in Tcl. Tcl has excellent XML-RPC support in the standard library and using SOAP is just so painful noone does it.
Jacob Levy
Thursday, July 6, 2006 2:32:58 AM (GMT Daylight Time, UTC+01:00)
For client developers, inclusiveness is great, but it's often very costly. So, you gotta pick which protocols you are gonna implement, which client you are gonna support. Then you weigh the costs and benefits. For most Web companies that seems to mean supporting REST (sorry Dare, XML over HTTP using REST principles) and SOAP (the Web RPC, not the bar in the bath tub) and not supporting XML-RPC.

BTW, I note your usage of the term REST is as lacking as mine. Hypocrite?
Comments are closed.