Web applications have a specific architecture, and this context has specific needs. How Fielding's "REST" came to be applied to application specific (non SOAP) XML formats is beyond me, but what Fielding actually wrote is the first best example of architectural principles for web applications. Beyond my own work on
"RESP", there are more principles that I need to enumerate for myself as I consider or work on commercial projects.
Avoid application silosThe extensibility of web service based applications will depend on a variety of small services that expose the data store independently from application processing. This separation permits the various views on the data and its applications to be represented cleanly, and allows for necessary evolution of these views as independent entities. The converse is a singular conception of the Web API, which evolution will get messy. A nice point of conversation is comparing the open RDBMS to one exposed only through Stored Proceedures. Each Stored Proceedure is another Web API, excepting the capacity of a Web API for some "varargs" style capacities in comparison with Stored Proceedures.
How dynamic is dynamic?If it's static, serve it staticly. Avoid implementing the world dynamically just because it's easy to do -- that's intranet, not internet. Use AJAX, Flash or Applets for the dynamic components of a Web UI. Evaluate alternatives in the context of an interchangeable server side.
Don't be afraid of a thick clientThe only problem with a "thick" Flash or Java client side is that the rest of the web is obscured from reusing or mashing the best parts of your wwweb. When the thick client uses documented Web APIs, then there's no issue. Frankly, browser space is hell -- even SVG is getting messy despite the most serious and dedicated efforts of its developers. For this writer the only thing that's sticking after all these years is the Java Applet. But even that subject is complicated, Java's accidents can be severe (final java.lang.String, class ByteBuffer, final class HeapByteBuffer, and the list goes on).
Less is moreIf there is no one size fits all universe (client or server side), its solution is really simple interfaces that can be picked up in a minute. That's what will survive your evolutionary forces and processes. Everyone in the game is making big mistakes: my own is not releasing anything for a decade, Amazon's is having a different authentication scheme for each service, Google's is having too few published APIs and not being API centric, Sun's is thinking that $1/cpu-hr is a business and generally having too little serious engineering discipline in the development of Java. The smaller the release, the smaller the mistake.
Use XMLThis one makes me laugh, in a "lol" sort of way, but it's true. It's the only way. JSON has too little structure, no attributes. It's a very good alternative format alongside an XML service -- serialize a DOM for XML or JSON. But XML is the canonical format, the best set of constraints for information service architects. The best Art recognizes its external constraints, then establishes project constraints, and then gets creative.
Think Universal SpaceIf it's all XML, data and processing, then there's a web universal space that we're all building an economy into. Forget discovery, let the search folks work on discovery. Drop design time at run time: SOAP. It doesn't scale. Use Schema, keep design time in it's place.
In summary, don't get aggressive on Requirements, get aggressive on Constraints, and then on getting creative and powerful within them. Work the problem. Save the World.
