REST vs. WS Statistics
For some reason I can’t really remember, I made a list of the SOA/WS-related blogs I follow and assigned them to three categories: supporters of Web services and the WS-* universe, supporters of REST, and some who support both (or don’t show that they care). In itself, this is not too interesting — it’ll be fun to watch whether the distribution changes over time, though.
I will of course happily make changes on request if I have assigned someone “wrongly” :-)
Web Services/WS-* supporters (10)
- Chris Ferris
- Christian Weyer
- Eric Newcomer
- Hartmut Wilms
- Jeff Schneider
- Jorgen Thelin
- Richard Veryard
- Ron Ten-Hove
- Steve Jones
- Ted Neward
REST supporters (15)
- Bill de hÓra
- Carlos Perez
- Dare Obasanjo
- Elliotte Rusty Harold
- Joe Gregorio
- Mark Baker
- Mark Nottingham
- Mark Pilgrim
- Patrick Logan
- Paul Downey
- Sam Ruby
- Sean McGrath
- Steve Loughran
- Tim Bray
- Yaron Goland
Supporting both (15)
Come on Stefan, you should have known better. I am definately with the “Supporting both” group, on my blog there is plenty of evidence for that ;-). Also, I am wondering which camp you belong to.
Duly updated ;-)
I started this blog 3.5 years ago as a firm believer in Web services and the WS-* vision, and have slowly and continuously changed my mind since then. I’m firmly in the (Lo-)REST camp today.
I expect SteveV would put himself in the “both” camp too, as would JeffS, MikeC, and PaulD. Fence sitters unite! 8-)
Doh, and Jim Webber too.
This has made me think. I am not formally in the REST camp, as I work with distributed objects (RMI) and WS-* by day. I think I too, am disillusioned with WS-*, mired down in the pain of WSDL and XSD editing, interop grief, etc.
I dont have enough experience of doing complex things in REST to say that it is better. I just know what I dont like. Maybe I should do a PhD in a REST-based-grid to understand it better, and really push the limits of the possible.
What about tuple-space and async message people?
I was unsure about Paul, but pretty confident in putting Mike into the WS-* camp. For Jeff and Jim, I can’t recall them ever supporting REST anywhere … An article by Steve Vinoski, though (http://www.iona.com/hyplan/vinoski/pdfs/IEEE-WebServicesInteractionModelsPart_2.pdf) clearly puts him in the fence camp, though. So I moved Steve and Paul and wait for further evidence on Jeff and Jim ;-)
Steve: The REST + WS + Both categorization obviously oversimplifies things; I’ll move you if you want … If I had an async messaging category, I would probably have put both Bill de hÓra and Sean McGrath there … and aren’t the REST folks automatically tuple-space folks, anyway? :-)
But you should definitely do that PhD.
Jim Webber’s definitely not a fan of service-specific interfaces, so I think that rules him out of the pure-WS-adoring group. Plus you’ve got Savas on the fence, and he and Jim are essentially the same person 8-)
OK, I’ll move Jim …
As Mark noted, I’m in the “supporting both” category. If I haven’t written anything supporting plain old HTTP recently, it’s because there’s no need to given all the articulate advocates out there … not to mention the fact that NOBODY is arguing that WS-* is worth the weight for typical public services on the web. I’m somewhat skeptical that pure RESTifarian approaches work as well as WS-* for “enterprisey” scenarios where multiple-protocols are a fact of life and a lack of security, reliability, transaction coordination, etc. can be causes of death, but I could be persuaded by actual evidence.
Thanks Mike - I’ll update again :-)
I am definitely not in the WS-* camp, so you have that right. And so neither am I in the Supports Both camp, so you have that right as well.
However I don’t see this as an either/or decision. There are many options for data transfer. Just because I would never choose WS-* should not imply I would necessarily choose REST/HTTP.
There are cases where I would consider a proprietary message queue, probably JMS at this point. There are cases where I would consider JINI/Javaspaces. There are cases where I would consider that too easily dismissed relational database. And so on.
Dude, I’m just glad to be on your radar at all :) One thing I like about how things stand now, is that a lot of heat has come out of the WS-*/REST debate compared to a few years ago.
I am a big big tuplespaces fan; really elegant model. They’re not getting traction tho’ - blame EJB and JMS, and Jini being difficult to get running ;) I think a lot about where IM tech like XMPP fits in, especially for grids and EDA; wish I had time to play around in that area more.
Based on his post at http://hyperthink.net/blog/2006/08/01/Really+Im+About+A+4+On+The+Tilkov+Scale.aspx I’m moving Steve Maine to the “both” category …
Stefan - if you move Steve there, then I expect you’ll have nobody left in your WS category, because I think all of those folks are of the view that REST’s good for some stuff, while SOA is good for others.
IMO, the criteria for being a “WS supporter” is that you believe there are a significant number of problems that can’t reasonably be solved within the constraints of REST, and that WS-* would do a better job at. By that measure, I think many from the “both” camp would be WS supporters; DaveO, Anne, Clemens, Loek, Don, Radovan, …
Mark, I guess your criteria would be valid as well — but I put those who would prefer REST over WS where possible in the “Both” category.
Arguably, to really make this meaningful, one would have to come up with a set of statements, sort of a REST or WS manifesto … but that sounds like way too much work.
Bill and others: I agree that — at least since I’ve started to follow it — the REST vs. SOAP debate has made a lot of progress towards an actual reasonable exchange of arguments. Which is great.
Er, I’m RESTian living in a world of SOAP.
Paul — does that mean you’re in the wrong category?
put me down as someone who has to support both ;-)
Thanks for including me in your list. Most of the stuff in my blog is at the business requirements end, so I tend to leave the WS/REST decisions to other people. I think it’s fair to say that my CBDI colleagues and I have been doing a lot more WS than REST. I did however post a layered diagram from the SPARK workshop, which was intended to show how the two camps might interoperate.
http://www.veryard.com/so/2006/03/spark-workshop-2.htm
Put me down in the “supports both” category. My blogs are at: http://www.xquerynow.com/cohensxblog and http://www.xquerynow.com/cohensxblog/simpleblog_view
and I’m writing a book titled FastSOA that shows the performance and scalability impact of choosing WS-* versus REST, among other things. Drafts of the chapters are available for free download at http://www.xquerynow.com/thebook
Also, you should put Tim Bray into the REST list. http://www.tbray.org/ongoing/ongoing.rss
-Frank
Where would you place the XML-RPC crowd? Or the more API based component or messaging approaches (with bindings which can abstract the actual transport),
Bernd
You mean there are people who support XML-RPC??
(Just kidding. I just hate it).
Those who consider HTTP a “transport” definitely belong in the WS camp, IMO.
I think Don Box express his position differently that is listed here. Please see: http://pluralsight.com/blogs/dbox/archive/2006/03/18/20246.aspx
You mean I should claim Don is not a WS supporter? That would be big news indeed :-) I guess I’ll have to leave him in the “both” camp …
Yes I think if you consider an AJAX based XML Request as XML-RPC (as opposed to REST) then there are some XML-RPC crowd out there.
But it is all too blurry. JSON for example is more heavy weight than a simple XML-RPC (using a XML subset) but still it is a REST application as it uses HTTP and non-XML.
Well, I am in the both camp, since there is not a single tool for each solution. I would not ask an AJAX developer to use SOAP, and I would not as a B2B Messaging with WS-ReliableMessaging to switch to HTTP-Post (and self made checksum/id headers).
Bernd
ARGH! No way .. I fully support both WS-* and REST. If you don’t need the complexity of WS-* then one should just use REST, absolutely. That’s the model we’re building in Apache Axis2 for example - the user get a nice clean view to the world whether its REST or WS-*.
No problem Sanjiva — I’m getting used to this moving people around :-)
Why is there no category: “Supports neither”
Basically because I was able to put everybody in one of the categories — although I agree some simply refuse to declare “support” for any particular technology.
REST ‘til disproved, and that’s with plenty of experience of WS-*
But where is Stefan Tilkov - that’s the real question?
Ooh! David, are you implying that WS-* has been disproved?
@Bernd: With XML-RPC, I was referring to http://www.xmlrpc.com/ — I’m not aware that typical Ajax applications use it. They’ll probably be using plain HTTP, RESTfully or not. You also seem to imply using HTTP without XML somehow equates REST, which I disagree with …
Me, I’m a REST supporter, doing more WS that I’d like to.
@Stefan: REST talks about specific usage of HTTP and especially URIs, it is also about re-using the HTTP Semantics (GET = ReadOnly). This means posting a Request as XML Document is NOT Rest. It is generally calles an XML-RPC, which is (admitingly confusingly) called the same as the SOAP Alternative XML-RPC.
AJAX sends XML requests, and this is not (pure) REST. Since it is not SOAP it is also not WS-*, so where would you put it?
What do you (both) mean by “(pure) REST”?
@Erik: well pure as defined in Roy Fieldings Dissertation (http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm)
XML is no necesary part of REST, in fact it is mandatory for REST to actually have method and object identifiers in the HTTP Request.
(sorry for double posting, feel free to delete the comment with the typo)
@Bernd: Looking at the documentation of XmlHttpRequest, e.g. here: http://developer.apple.com/internet/webcontent/xmlhttpreq.html it is perfectly feasible to use it to do RESTful GETs — the “XML” in “XmlHttpRequest” seems to be a misnomer.
I agree that doing read requests via POSTing XML would be entirely unRESTful, but that is orthogonal to Ajax — i.e. one can do Ajax requests in a RESTful or unRESTful way, or use Ajax to do XML-RPC, or to invoke a Web service via SOAP.
I want to be moved to the “both” list. I have always advocated that there is value to both approaches. AWS also supports both and it turns out that none of the applications developers actually care what goes on the wire or how urls get constructed (REST-style is often used from perl/php libraries - SOAP mainly from Java & .NET toolkits).
Thanks for the comment Werner, you’ve been moved ;-)
@Bernd: (sorry for double posting, feel free to delete the comment with the typo)
Oops. I was reading all of the comments up and down a little two quickly and didn’t realize you doubled your post — I thought I saw two different comments (hence the “both” bit). Sorry if it seemed snippy!
XML or not, if I want messages that unambiguiously convey business intent, portions of that intent might be manifest in the URI strategy or in payloads. I’m trying to find the best approach.
The phrase “pure REST” was interesting to me. I haven’t yet surveyed the REST dissertation — or the underlying RFC’s — well enough to know what constitutes impurity. But I’m sure I’ve crossed the line more than once already!
I recently performed a little hack and slash editing of the REST wikipedia article[1].
Perhaps it will be of use to those web services guys still figuring out what REST is.
Benjamin
[1] http://en.wikipedia.org/wiki/RepresentationalStateTransfer
Hey Stefan,
I swing both ways :-) Actually Savas and I are currently writing a book on Web-inspired integration…
Jim
Cool — looking forward to it :-)