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.

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.

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.

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.

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).

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.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.