So you've been reading the many recent articles on the Web about REST, how it's the future of Internet architecture, and you've decided to begin applying some of it in your work. But when you start digging into the subject, REST by itself seems to be about moving data resources from one place to the other over the Internet, not building complete applications. It's unclear (and certainly poorly documented) to you how to situate it properly in context; a fully realized and well-designed piece of software.
You start wondering how REST is used specifically (and strategically) in an application or overall software architecture. In other words, what are the moving parts and rules for applying them. You also wonder what else you should aware of that can be used in conjunction with or to complement REST and make it better. You might even want to know when to break the rules and use other related approaches. This is where something known as WOA becomes useful.
WOA as a complete REST architecture
This is where a deeper discussion on Internet applications and specifically, Web-Oriented Architecture (WOA) comes into the picture. WOA creates a more sophisticated and up-to-date vision for modern Web applications that aligns gracefully with the grain of the Internet. It also is generally (but of course, as with any approach, not always) true that WOA applications are easier to build, connect to other systems, and maintain for the Internet (and yes, Internet-type networks, like your enterprise intranet.)
Why is WOA generally so much better than traditional service-based architectures? Because WOA is an integrated, emergent architecture that is born out of countless lessons learned about what works and what doesn't when designing software for the Web. It's not created by a big software company, it's not a commercial piece of software, it's not a giant set of standards from a standards body.
Instead, WOA is just what developers are doing lately and more and more of it is showing up in our favorite Web application frameworks like Ruby on Rails, Django, and the nascent cloud computing platforms. In other words, it's a set of best practices for designing Web applications. And it's not a grab bag of approaches and technologies, it's actually a fairly elegant model that works: It's secure, it scales to the Web, it performs, it's all those other things that we like when we are idealized lazy programmers. WOA is also generally simple to work with, easy to implement, and usually is intuitive once you understand the Web. Note: One exception to this is REST being "the engine of hypermedia state", that certainly takes some genuine noodling over to understand. I'll see if I can tackle that in an explainable way in the near future, since it's one of the best and most important parts of REST. In the meantime, a walkthrough of Sun's RESTful Cloud API perfectly illustrates this concept.
So, in short, WOA is much more than REST and REST is the foundational architectural style for WOA.
You can see all the key elements in the diagram in the upper right of this post. It's a good start at understand what's essential about WOA (which at its core is about RESTful approaches to software) and what else you can do with it. Chances are good you'll end up using things like JSON and ATOM. Perhaps to a lesser extend things like OpenID or OAuth, though you should definitely put those on your to do list.
A more exhaustive list of things that are WOA is below. Many of them can be used in non-WOA ways (in other words, breaking RESTful principles). Don't use them that way. Instead, think about resources, links, and hypermedia and how to compose, distribute, and consume them.
The Aspects of Web-Oriented Architecture
- Transfer Methods. This is at the core of REST and ROA and is the foundation of Web-Oriented Architecture. You can read Roy Fielding's chapter on REST (he conceived of the approach originally) or you can just follow the simple guidelines here. At other times, protocols like BitTorrent can be used if the requirements warrant it, but these are exceptional scenarios that I will cover at some point in the future.
- Data Representation. Just about anything that HTTP can transmit can be your state representation which you can then compose, distribute, etc. XML is standard and JSON is getting more and more popular but it can even be an image or other media, though in general, the simpler the representation, the more consumable it is.
- Data Portability. Getting your data into and out of WOA-based systems requires some support for a few standards. In particular, being a good Web citizen requires paying attention to these, even if most users or customers don't ask for it upfront. Eventually, they will want it, need it. Fortunately, these are also pretty straightforward.
- Security. Internet security is a major and ongoing topic and securing you WOA applications requires more than just SSL, which is really the only option with HTTP that is widely recognized and universally used. SSL has also never been compromised. But user identity especially is evolving very quickly on the Web right now and open security/identity approaches like OpenID and OAuth need to be in your architectural plans these days. Both are also very WOA friendly.
- Composition. Building applications out of REST services is a whole set of techniques in and of itself. Hypermedia is of course the core model for composition and your Web pages or other code will operate directly on resources with RESTful design principles. Mashups and and Web widgets and gadgets are important too. OpenSocial and other emerging social networking application standards (which work best as, you guessed, WOA apps) are also becoming important as well but have some potential for lock-in and their eventual success is still unclear.
- Distribution. Getting your services out there and consumed is still an art form, but the technologies are straightforward. HTTP is of course the canonical way to access REST resources but going the full API route is the best way to get them consumed. Widgets are thus a key distribution strategy (on the push side) in addition to being a composition strategy (on the pull side).
If you on the enterprise-side of the story and wondering how this will affect you, please read my recent examination of WOA and SOA.
Update, June 8th, 2009: Dave West over on InfoQ did a good summary of this post today in REST is a style -- WOA is the architecture.