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).
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.
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.
Flash seems to miss decent http support
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.
Re: Flash seems to miss decent http support
+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!
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!