Web Things, by Mark Baker

InternetWeek published an article about REST as a different approach to Web services today. Some good stuff, but the conclusion of the article misses the point.

Perhaps this point doesn’t get made enough (hah! 8-), but not only is REST is an alternate approach to building Web services, it’s superior in almost any measurable way I can think of. Not all architectural styles are created equal, obviously, and not all are suitable for Internet scale deployment; REST is, Web services aren’t.

Dave Winer points to an interesting question from Daniel Berlinger; Why wasn’t the Web built on FTP?

This, and related ones such as “Could the Web have been built on FTP?”, or even “Why did the Web win, and not Gopher?”, are excellent questions with really interesting answers that expose historical, political, and technical aspects of the World Wide Web project. I don’t pretend to have all the answers, but I’ve done my research, so I think I’m a good person to ask (of course, you could just ask Tim for the authoritative answer)

I think the answer to Daniel’s question is pretty easy; Tim chose to start with a new protocol, because he was innovating and FTP was well-entrenched at that time (if he even considered FTP at all, I don’t know). Tim’s (and later, Roy’s) innovations would have required substantial changes to FTP too (support for URIs, and the fallout from that being the big one), so I think it was a wise choice.

So, could the Web have been built on FTP? I’d say probably not, no. Other than the aforementioned points, other things that would effect this would include;

• FTP uses two network round trips for each retrieval, due to first-pass negotiation
• FTP has no redirection capabilities
• FTP doesn’t have a POST method
• FTP implementations don’t permit delegation to plugged-in software

There’s probably more issues. Add those to the fact that FTP was RFCd in 1985, eight or nine years before Web standardization began, and there’d be a lot of pushback from the IESG to changing FTP into something that it wasn’t intended to be. And rightly so.

Jorge*n* Thelin (I mispelled his name before, my profuse apologies to Jorgen) catches up on his messages to me. Either that, or he’s obsessing. 8-)

I don’t know how I’m going to respond to all of that, especially in my weakened condition. For now I’ll just respond to the most recent one first.

Jorgen says;

I think the reason why Mark gets such pushback from his suggestions about defining the “architecture contraints” for Web Services technology is because I believe these principles don’t exist as specific “constraints” any more than the REST approach is a “constraint” defining the ONLY way to write applications that use the Web.

That’s true, constraints don’t “exist” per se. They’re just guidelines that are followed in order to realize useful properties. For example, when you’re driving your car, you follow certain constraints that serve to maximize the safety of yourself and other drivers, while still preserving the ability to get to point B from point A. Sure, you can ignore some constraints (like driving on the left hand side of the road 8-), but then useful properties (like your safety) are sacrificed.

It is still perfectly possible to write stateful web applications just as it is possible to write stateful web services. In both cases, it is bad practice to do this from many viewpoints (scalability being the obvious one), but it is certainly not completely precluded and actually in some scenarios there are no options but to use a stateful approach – it all depends on the application and usage scenario whether that is a valid approach.

That’s also true, but you have to realize that useful properties are being sacrificed if that’s done. Sometimes the sacrifice is worth the gain, but other times it is not. I’ve said before that I consider REST’s stateless constraint to be it’s second most important constraint. But it’s a far cry from the most important constraint, the uniform interface. I’d say that 95% of the Web’s utility and success derives from the useful properties induced by this one constraint. I cannot think of any reason why anybody would need to sacrifice this constraint that has worked so well. The reasons I’ve heard given, are that this constraint restricts the function of the architecture (equivalent to a “rule of the road” preventing you from driving to certain places), specifically that the Web is for humans, while Web services are for machines. But that’s simply not true.

Jorgen Thelin points to a John McDowall blog about Architecture by Intent in which John talks about how Linux kernel upgrades requiring hardware upgrades is a bug requiring more architectural emphasis to fix.

When I first read Jorgen’s blog, I assumed that John was talking about Web services; I have a one track mind, I know. But I’ve tried to ask Web services proponents what the architectural constraints of Web services are, and even made a good faith effort to write them down (as compared to REST), only to have the attempt called a blatant troll.

So somebody please tell me; what are the architectural constraints of Web services? If nobody knows, then aren’t Web services “Architecture by Accident”? But if they are known, let’s sit down and figure out what properties these constraints induce so that we can tell if they can do what people want them to do. Yes, that’s a challenge.

Dave Winer says;

SOAP and XML-RPC were started to make it easy to build applications that viewed the Internet as if it were a LAN.

which is 100% true, and at the same time, 100% the wrong thing to do. The Internet is not a LAN. On a LAN, there’s one administrative/trust domain, and on the Internet there’s, well, a whole lot more than one. Computing in those two domains – LAN and Internet – is not the same thing, and therefore requires different solutions (though arguably it could be said that the LAN is a special case of the Internet, where number of trust domains = 1, so what works for the Internet could also work on a LAN – but the converse obviously doesn’t hold).

And for the record Dave, I write software, thank you very much (and so does Paul). Not as much as I used to, but I still do, and still enjoy it (especially now that I’ve switched to Python from Java). It’s all too easy to put down a detractor rather than trying to understand what they have to say, I suppose.

Just posted a new blog at my O’Reilly weblog about SOAPAction.

Greg Reinacker responds to the earlier discussion Jon Udell and I were having about uniform interfaces. The emphasis of his response is on my generalization post to www-ws-arch, in particular the part where I generalized from getStockQuote() to getQuote(). He may very well have a point that this step is pointless, I don’t know. But it was just an example of a step; perhaps a better example could be found. The main point of the post was the first step and the last; from the unparameterized, good-for-retrieving-one-thing-only method, to the good-for-any-safe-retrieval method.

Then, as I responded to Jon, the value of doing that is because deploying new interfaces is extremely expensive. If you’ve got an interface that can do what you need, then you’re better off using it.

Greg did have this to say in his conclusion, which I’d like to comment on;

You can retrieve anything the same way, but you can’t process it without knowing more specifically what it is.

I can’t emphasize enough how important this point is. Being able to retrieve anything is a big win. Processing it is indeed an issue, and a non-trivial one (as I just alluded to), but with Web services, you’ve got both the problem of being able to get the data and the problem of knowing how to process it. The Web solves the first problem, and that’s just with the GET method!

Michael Radwin reports from ApacheCon 2002 about Roy Fielding‘s presentation on Waka (his planned HTTP 1.1 replacement), and Web services.

There’s a lot of good stuff in Roy’s (PPT) presentation, but Michael appears to get the point Roy was making about Web services backwards. They don’t solve the N^2 problem, they are the N^2 problem. REST’s uniform interface constraint is what drives the complexity of integration to O(N).

So quoth Dave Winer;

After all these years, I’ve concluded that if I can’t understand it, it doesn’t have much of a chance in the market.

Well, without taking potshots at Dave, I think this is a fairly poor way to judge a technology. The interaction of a technology with its users is an incredibly complex environment that has no single metric that can indicate the success or failure of that technology. But what I look for in any technology, is network effects.

I haven’t talked much about RDF or the Semantic Web in my blog yet, so I’ll just say a quick word about them.

The Semantic Web is the Web with an additional architectural constraint that could be called “Explicit Data Semantics”; that data (representations, in the case of the Web) will be constrained to be explicit about its implied semantics. This adds the additional desirable property to the system of partial understanding. In a nutshell, this basically means that you get to avoid the “schema explosion” problem, where you have a bazillion different XML schemas, and understanding them is an all or nothing proposition (i.e. where software only understands the schemas it was programmed to understand). RDF and the Semantic Web doesn’t change one important thing; software will not “know” anything more than it was programmed to know. But it does allow a single piece of software to be able to do whatever it is that it does, on any data anywhere. For example, I could write software that searched for “people”, and it could find references to “people” in many different XML documents if RDF were used. And that generates network effects up the wazoo.

Finally, I was asking them for this over two years ago! The mod_pubsub project has been established at Sourceforge, with IFindKarma leading the way.

I’m sure I’ll be making use of it, perhaps on this very blog.