Building RESTful services with Flash

Flash has become central to a lot of popular web sites. But it also has its detractors. And now it seems that despite its wide use, it's not possible (or easy) to use it in a RESTful manner. Apparently Flash browser support only copes with GET and POST operations, won't allow overloading of POST (to simulate PUT and DELETE) and doesn't work with cookies (note to the author - check out REST anti-patterns!) Fortunately Duane Nickull, co-chair of the OASIS SOA Reference Model TC and Adobe Evangelist, has some things to say concerning that article.

The architecture of Flash has been done right and is in alignment with the core principles of SOA, as defined by the OASIS Reference Model for SOA, an abstract model which describes the core principles of SOA at much the same level of abstraction as Roy Fielding's doctorate thesis on REST. Flash is also in alignment with the core principles of REST.

As others, including Duane, have pointed out, REST is not tied to HTTP. It's entirely possible to design RESTful services and applications using other technologies. Duane then describes why he believes only GET and POST should be supported and it's related to fundamental SOA requirements:

The SOA-ish way to architect applications is to keep the semantics of data management out of the transportation workhorse where possible. There is not hard set of rules for this yet many architects I talk to seem convinced this is the best way to build. Every service has an associated data model and action model for processing the service invocation. The data model is the data and the processing/action models are the place whereby the "verb" of the service invocation can be expressed.

So ideally layers in an architecture should be independent of each other wherever possible and is one of the reasons why the W3C Web Services Architecture working group chose to only support GET and POST in SOAP. And this is also a reason for the limited verb support in Flash. To support this statement, Duane refers to Roy Fielding's thesis (section 6.3), which states at the beginning ...

The key problem areas in HTTP that were identified by REST included planning for the deployment of new protocol versions, separating message parsing from HTTP semantics and the underlying transport layer (TCP), distinguishing between authoritative and non-authoritative responses, fine-grained control of caching, and various aspects of the protocol that failed to be self-descriptive. REST has also been used to model the performance of Web applications based on HTTP and anticipate the impact of such extensions as persistent connections and content negotiation. Finally, REST has been used to limit the scope of standardized HTTP extensions to those that fit within the architectural model, rather than allowing the applications that misuse HTTP to equally influence the standard.

Duane then goes on to discuss why an architect would want to stay with GET and POST, irrespective of whether they are using REST or SOA). For instance, consider DELETE: this would mean exposing a very specific semantic that may not be available to all consumers (non-authenticated) of a specific server.

If you want to expose this for consumers of a service, my preferred way would be to build a second service exposing this but keep the back end processing semantics in the payload (SOAP body in many cases).

The debate about PUT and POST has raged for a while (relatively speaking) and Duane has this to say:

Some have equated PUT to be synonymous with an INSERT in SQL terms and POST to be equivalent to CREATE. While this is sort of true, in the real world, the physical bytes of both operations overwrite the existing copy of a resource hence it is really an UPDATE in CRUD terms.

And it is worth noting that PUT is not something that must be supported in order to be called RESTful. Finally there's the issue about cookies that the original article raised. Stefan Tilkov discussed a series of REST anti-patterns and cookies were one of them, at least when not used carefully.

Cookies are a sure sign that something is not RESTful. Right? No; not necessarily. One of the key ideas of REST is statelessness – not in the sense that a server can not store any data: it’s fine if there is resource state, or client state. It’s session state that is disallowed due to scalability, reliability and coupling reasons. The most typical use of cookies is to store a key that links to some server-side data structure that is kept in memory. This means that the cookie, which the browser passes along with each request, is used to establish conversational, or session, state. If a cookie is used to store some information, such as an authentication token, that the server can validate without reliance on session state, cookies are perfectly RESTful – with one caveat: They shouldn’t be used to encode information that can be transferred by other, more standardized means (e.g. in the URI, some standard header or – in rare cases – in the message body). For example, it’s preferable to use HTTP authentication from a RESTful HTTP point of view.

In conclusion, Duane agrees with others who state that SOA and REST are often good together. Furthermore, the architecture of Flash is true to the core principles of REST and SOA, with the runtime supporting the right level of functionality, i.e., it should be possible to develop RESTful services with Flash.