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.
Community comments
Flash seems to miss decent http support
by Peter Coppens,
Re: Flash seems to miss decent http support
by Valery Silaev,
Hold up there a second!
by James Watson,
Re: Hold up there a second!
by Ryan Riley,
Flash seems to miss decent http support
by Peter Coppens,
Your message is awaiting moderation. Thank you for participating in the discussion.
Not trying to get into the muddy waters of what is REST or SOAP and what they are good for...but the fact that flash puts limits on the http verbs one can use or e.g. how it behaves when non 200 status codes are returned from the server make the platform inherently flawed for any decent http based communication with a server that is not under the control of the client developer. Just try to get a flash app going with any existing http based REST service that was not written with a flash client in mind. Or implement file upload in an environment with enterprise proxies. I for sure had to give up, but obviously always interested to learn how others were able to pull this through.
Even when the server is under the control of the client developer, if the goal is to also support more typical http/rest clients, one soon gets into client dependent code (filters) on the server end. It's sad really....why would a platform vendor implement only part of a well established standard? Users really do not need to be protected from themselves....if at all, they might need to be protected from vendor lock-in.
Peter
Re: Flash seems to miss decent http support
by Valery Silaev,
Your message is awaiting moderation. Thank you for participating in the discussion.
Peter,
+100 to your point.
I share the same frustration with the state of HTTP support in Flash. It's a shame that RIA (to recall, "I" is for Internet) platform lacks so much HTTP-related functionality. Personally I hit the wall several times when it was necessary to add WebDAV / CalDAV / CardDAV support to Flash application.
All these academic debates whether or not REST requires verbs beyond GET/POST is irrelevant for me (btw, PUT vs POST issue is well explained here -- jcalcote.wordpress.com/2008/10/16/put-or-post-t...). I just want Flash to support R-E-A-L requirements. And the reality is that there is a lot of widely accepted HTTP-based protocols using PUT/DELETE/OPTIONS/PROPFIND/PROPPATCH/whatever else verbs. And custom headers. And it's just insane that from the same HTML page I can use HTTP features up to full extent with XmlHttpRequest but not with Flash plugin.
Same is for cookies: keeping session identifier as a cookie is a norm, please just make it work in all browsers (as of Flash 10 and prior, FileReference.upload in Firefox lost all non-persistent cookies of the parented SWF).
For me Duane's article sounds like protecting Flash bugs/limitations with questionable architectural benefits.
Hold up there a second!
by James Watson,
Your message is awaiting moderation. Thank you for participating in the discussion.
Where is the idea that POST is used for updates coming from? I just double-checked my "RESTFul Web Services" book and PUT can create or update (or replace) a resource. POST is for creating resources (always subordinate) but never updating them.
Things are going to get ugly or RESTful web services if we can't keep things like this straight. If you people want to use HTTP differently, that's fine, just come op with a different term, please.
Re: Hold up there a second!
by Ryan Riley,
Your message is awaiting moderation. Thank you for participating in the discussion.
@James: You are correct on the semantics of PUT. However, POST is fine, per Roy: roy.gbiv.com/untangled/2009/it-is-okay-to-use-post.