Application Platform Strategies Blog

REST: Is it the Next Big Thing?

Blogger: Anne Thomas Manes

The APS team has been involved in a vigorous debate about REST for the last two months. Certain members of the team contend that WS-* has become bloated, unwieldy, and overly complex, and they fervently believe that we should not be recommending it any longer. Our resident RESTian also cites the fact that WS-* has no contraints, and therefore there's no way to ensure the properties and characteristics of applications built with it.

So if WS-* is a tragic mistake, does that mean REST is the next big thing?

Perhaps so. Vendors like IBM and Microsoft are starting to make major investments into technologies and frameworks that facilitate development using the REST architectural style. But for the moment, a steep learning curve and the dearth of available frameworks will stymie adoption. (For those looking to get started with REST, I recommend RESTlets.)

REST is not simply technology--it's an architectural style that's fundamentally different from they way most developers design systems today. It requires a noun-oriented approach to designing systems rather than one based on verbs. I know quite a few people that have been studying REST for years who still struggle with RESTful design practices. Understanding the basics of the style is easy. Truly groking it and being able to apply it to real-world situations is much harder.

Here are the basics:

• It is a resource-oriented style of design
• Every resource is addressable via a URL
• Every resource has a uniform interface
• State is exchanged via representations
• Messages containing representations are self-describing
• Interactions are stateless
• Representations reference related resources via hyperlinks

Note that REST is not the same as "plain old XML" (POX). POX refers to the format of a message payload, and it says nothing about architectural style. It just says that you don't wrap an XML message with an XML envelope (e.g., SOAP or Atom). More to the point, not all POX applications are RESTful, and not all RESTful applications are POX.

Likewise, REST is not the same as HTTP. HTTP is an application protocol. It's middleware, not an architectural style. It just so happens that HTTP is the only application protocol that fully supports the REST constraints. But a developer isn't forced to adhere to those constraints. In fact, not all HTTP applications are RESTful, and developers frequently use POST to tunnel method invocations (verb-oriented style). Also note that REST doesn't mandate HTTP, but it is the only standard protocol that implements REST constraints.

For those interesting in learning more about REST, I encourage you to sign up for Pete Lacey's half-day workshop, REST Easy, at Catalyst on Tuesday, June 26, 2007, in San Francisco.

Lights on at Catalyst 2007

Blogger: Chris Haddad

Catalyst attendees experience truthful and thought provoking discourse that influences how technology champions and decision makers shape IT strategy. This will be my fourth year at Catalyst (and my first as a master of ceremonies), and I am excited about the opportunity to catch-up with perennial attendees and hear about the challenges, opportunities, and progress real-world enterprise projects are making towards reducing complexity, delivering a rich user experience, and realizing their path towards SOA nirvana. Transforming IT architecture and gaining solution delivery team adoption is a non-trivial task (if it was easy, the terms 'guru', 'wizard', and 'expert' wouldn't be associated with the technology domain). Change agents are searching for answers, and Catalyst delivers a real-world perspective. For example, sessions will factually address the popular questions I hear while out in the field; “Is anyone successful at SOA?” and “How does a COTS strategy impact my architecture plans?” Over the next twelve months, many organizations will decide if SOA and architecture transformation is a dream, distraction, or a nightmarish project fraught with too many pitfalls. Catalyst attendees have a unique opportunity to question Burton Group consultants, analysts, and peers and learn if a service-oriented led IT transformation, a rationalized architecture, and a unified user experience are fantasies or realities. I look forward to talking with you at Catalyst!

I say Data, You say D-ah-ta

Blogger: Lyn Robison

Data is used both as a plural noun and as a singular mass noun. Data consists of raw observations. Data is (or data are) pieces of information without context.

In IT, do we deal with data or do we deal with information?

Consider the fact that information is data in context. Information has meaning, where data might not.

Businesspeople tend to have greater understanding of the contextual meaning of data than IT people do. So it seems like businesspeople deal more with information, and IT people deal more with data.

Based on this line of thinking, in my communications on this topic, I plan to use the word information from a business perspective and the word data from an IT perspective. That approach would seem to form a clear line of demarcation between to the two terms.

So, when you see me talk about information, think business. When you see me talk about data, think IT.