Is it? After all what is the goal of architecture in an IT context? Surely its to represent what the business wants to achieve. Looking at the Wikipedia definition of Enterprise Architecture for instance it says
Enterprise Architecture is the description of the current and/or future structure and behavior of an organization's processes, information systems, personnel and organizational sub-units, aligned with the organization's core goals and strategic direction.
And System Architecture goes down as
A system architecture or systems architecture is the design or set of relations between the parts of a system.
Now this is what I've always thought of as being architecture in an IT context. Even something very very techy like ADML describes software architecture as
A software architecture describes the structural properties of software, typically the components and their interrelationships, and guidelines about their use.
The key bit here is it describes the OPERATIONAL pieces (components and interactions) rather than the implementation mechanics.
Now I don't think this fits what REST is at all. REST deals with the implementation mechanics and the principles and practice of that implementation, it doesn't provide you with a style for the modelling of an architecture and its interactions, it provides you with a framework for its implementation.
In his presentation Roy uses the phrase "Architecture is trying to find the common design" before going to talk more about architectural style being more abstract that that. Now the issue here is that in architecture he talks about implementation protocols as being the key to the Web "architecture". REST then becomes one level above that talking not about the protocols but about the "style" of the Web. Now this really got me thinking. This is a long way away from what I mean when I talk about business architectures and it really is about implementation practice... then it dawned on me, this isn't an argument about architectural styles, in fact REST isn't an architectural style.
REST is a design pattern
In software engineering ,a design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.
Now that to me sums up exactly what REST is, and how the Web is the implementation of the REST design pattern, and explains how the REST design pattern can be used to implement your projects and programmes. This doesn't make REST any more, or less, relevant to decisions but for me it explains the different between SOA, as a business driven concept, and REST as an implementation model for that approach. It is fair to say that Web Services has a lack of patterns and practice and that this is an area that should be addressed in terms of Web Service implementation patterns (and anti-patterns), but both REST and Web Services are fundamentally about technology and implementation.
Architecture needs to be about understanding the goals and objectives of the business problem being solved and about the effective modelling of that solution. This then needs to be translated into technology by creating a software architectures which are based, or constrained by, firm design patterns that ensure repeatability of solutions. Confusing the goals of architecture by making it focused on the technology implementation really doesn't help us bridge the gap between IT and the business, indeed it reinforces the gap by emphasising the IT focus as being on technology rather than on the business problems.
REST may well have a place within the implementation of an Enterprise or Solution Architecture, but we shouldn't confuse the goals of architecture (business problem) with patterns (IT implementation), and REST belongs firmly in the later.