Web Services discussion worth watching

One of the main advantages of web services is that your data storage will be on the service provider's server. That way you can access your application from anywhere.

But it also means that if the service provider goes out of business, or decides your critical application is no longer profitable, you're screwed.

The photo and remote backup hosting providers have so far escaped liability, so I imagine the providers for critical services will too. And anyway, provider liability is not what you want - it's your data back, which so far many people have been unable to get.

Loss of data stored on hosting provider's servers is already happened. It's a reality. It will only get many times worse when Web Services is widespread.

Imagine that it's not the only copies of your photos of your dead brother that you lose, but the payroll history for a medium sized company.

I will have more to say on this topic.

i'm only guessing. Does this discussion have anything to do with that annoying "ad.doubleclick.net not found" message?

I imagine that simonstl can only be depressed by the first two responses to his article, and may be seriously reconsidering the value of his participation at Advogato.

C'mon, people... Get with the program.

I suppose there is a significant faction here that will not or cannot do Deep Architectural Thinking about big systems like the Web. (I knew they were here; I just didn't expect them to be quite so vocal about their ignorance.)

Enough venting...

To boil the Web Services conflict down to one of pragmatism versus idealism is perhaps somewhat unjust, but not entirely, IMO. The REST camp suffers from the same problem that plagues the Semantic Web camp (though not to the same degree): a failure to present their ideas in a way that is accessible to The Average Web Developer. Part of the reason people understand SOAP (or at least think they do, which is arguably more important) is precisely because it doesn't have all the philosophical and intellectual baggage that is needed to justify the constraints present in approaches like REST. Valid or not, the relevance of these constraints is only as great as the number of people who understand why they're there.

At this point we are stuck with SOAP for a while, for better or worse. Those who prefer a different approach should let SOAP go its own way, and make it part of their job to ensure that the SOAP camp is equally accommodating to alternate approaches. And the REST folks should take this experience to heart: this is what happens when, in pursuit of lofty goals, you lose touch with the needs of the average developer. Keeping him happy is key to the realization of those goals.

The first two replies weren't so bad - "Web Services" still means a lot of different things to different people.

As far as the pragmatism vs. idealism angle, there's a lot more depth to this than "REST is aesthetically more pleasing and SOAP appeals to the average Web developer."

REST _is_ what most Web developers do every day, without really pondering it that hard. I don't see anyone building Web sites, for instance, that use a single URI and expect users to send POST requests to get back different pages. (I may have to build one now, just to be perverse.)

As stupid as that sounds on its face, that's precisely what SOAP does for program-to-program communication. I don't mind request-response for developers - I just want it done in a context that makes more sense. that could mean switching to a different framework, like BEEP, or it could mean considering how this works within the framework of the Web, and that's probably REST.

I'm happy to see SOAP go its own way. I'd just like it to:

I guess I was excessively cranky starting my last response. Still, it's not like you, simonstl, haven't provided context for the points you're making. Of course the term "Web Services" is deliberately vague/misleading because it gives the marketers the greatest leeway in their... ahem... projection of the concept's potential.

REST may be what most developers are doing now, but that's a matter of technical convenience rather than ideological following. Where a SOAP-style approach is more convenient to implement, it will win.

What factors might make the SOAP approach more convenient to implement? How can the W3C make it a more attractive proposition for implementors to stick to the REST model? Have any vendors made a commitment to support the REST model with REST-friendly tools? I bet the answer is "no".

If REST is to succeed as a dominant Web design philosophy (rather than just another way to go about doing things), get Sun on board. Alienated from the WSI, they may find the prospect of a Better Way attractive. Sun needs an acronym (from somewhere other than Microsoft) to demonstrate to the trade rags that they are serious about playing in the same space as the WSI; REST needs tool support that validates its concepts explicitly.

Your questions about selling REST are well-taken, but there's some serious irony to them.

REST isn't a "thing" in the same way that SOAP is or even BEEP is. SOAP is an explicitly specified protocol framework that has XYZ processors for XYZ environments. These toolkits are labeled "SOAP" or "Web Services" explicitly.

REST is pretty much riding on existing Web practice to get work done, not an explicitly specified new-and-different framework. There are hundreds, probably thousands, of REST toolkits out there, but they have names like the Apache HTTP Server, Java XML data binding, XML::Parser, etc.

Asking people and vendors to support REST is kind of like asking people to support air. We all breathe it all the time, and sometimes do other things with it. I see SOAP as polluting that air, but a lot of people don't mind smog as long as they can drive their SUV to the mall.

I suppose it's possible to create toolkits around these things, but it's pretty much development-by-accumulation, rather than coming up with new conglomerations to market and heck, maybe patent.

Would you like some oxygen with that nitrogen?

I realize the relationship of REST to existing practice. But of the tools you mention, how many can be used to subvert the REST philosophy as well as implement it? It seems to me like such subversion could occur relatively easily, and thus naively. What I'm getting at is that REST proponents need to find a way of highlighting those practices that are REST-kosher, and those than aren't. And then see to it that the tools make it easy to do the Right Thing, or at least difficult to do the Wrong Thing.

The REST camp suffers from the same problem that plagues the Semantic Web camp (though not to the same degree): a failure to present their ideas in a way that is accessible to The Average Web Developer.

It's funny you say this, because just this week I gave a talk and write a paper trying to solve this problem. It's called The Semantic Web (for Web Developers). I'd appreciate your feedback.

Meanwhile, I agree that we need tools to make writing REST code easier. I know that mnot and amk are working on some.

As someone who's been watching "Web" services evolve in the background for a while (my experience with XML/HTML is mostly in the document rather than data areas), this was an interesting read.

My feeling, after reading all this (and thinking I have a pretty good handle on it) is from the point of view of a content creator, REST is the better solution. I believe you're right when you say it's what we've been doing all along. Having only passing knowledge of SOAP-RPC, I was surprised to learn it has a single URI interface to everything - I thought it was just a formalization of some data structures in XML, but apparently it's also a new "HTTP" interface that neglects unique URIs, which I think is anathema to the structure of the web as it is now.

Upon reading the above paragraph, I find it extremely trite, since obviously this was your point all along. But I guess it might be good for me to say that as a "user" rather than "developer" of these things, I prefer the REST approach over the SOAP one.

(I also think it's hardly an idealism v. pragmatism issue; in fact, I think this really isn't much of a factor at all, except that ideally technologies are perfect, and practically they often end up not being so. What's "easier to implement" doesn't seem to be an issue here, since REST doesn't need to be implemented per se.)

Well, I'd have to agree with Dave Winer for once; I'd rather see Google and Amazon offer these interfaces - - regardless of implementation method in the short-term, than not have them at all...

But...

From my experience it's been tricky to dodge the SOAP bus, not only because of the platforms we're deploying on, but due to the Microsoft press that our local PHBs have been buying into. It's an unintuitive framework in many senses, and seems overly verbose for some of the uses we've been toying with in recent months. However, technical arguments don't always win with marketing pushes... ;-)

The larger problem from my perspective is trying to pick a solution for both in and out-going feeds that is consistent accross the board, supports our client's needs, yet remains "clean" in implementation (for argued values of "clean"). Given our client's tendancy to not be fond of XML in the first place, and that they are often running legacy systems, I am at least lucky in the short-term; we're pretty much working with a REST philosphy here atm, yet I have the breathing space to look around and follow the arguments whilst keeping my eye on our future direction. Somehow, given the type of clients we have, I think that future direction will be dominated by SOAP.

I am however, desperate to see some concensus of opinion on the matter. edd's thoughts echo much of what I, and many of my collegues have been feeling for a while, but I'm not too sure I'd like to see XML/ Web services develop outside the W3C either. That's a beast that won't be tamed when it's wild. However, if it's in the zoo...?!

At least with traditional HTTP I know *all* our clients will be able to integrate with their existing systems in some shape or other, and that's enough of a reason to watch the discussion for a while longer IMO.