TheArchitect.co.uk - Jorgen Thelin's weblog

Web Services Architecture Constraints

Mark Baker posted his recent experiences trying to define the architectural principles behind Web Services:

[...] 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.

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.

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.

I think we need to start refocusing our minds away from the REST vs SOAP debate (which is pointless anyway because both sides are right up to a point!), and instead concentrate on the "web best practices" described in the REST model, and look at how those principles or design patterns are applied in the context of Web Services technology. This is some work I am doing in conjunction with some speaking engagements and articles for next year.

It is only by defining these "design patterns" or "best practice approaches" that we can ultimately turn "Architecture by Accident" into "Architecture by Intent"