Is it feasible to create a REST client with Flex?

I'm starting a project using a Restful architecture implemented in Java (using the new JAX-RS standard)

We are planning to develop the GUI with a Flex application. I have already found some problems with this implementation using the HTTPService component (the response error codes, headers access...).

Any of you guys have some experience in a similar project. Is it feasible?

The problem here is that a lot of the web discussions around this issue are a year or more old. I'm working through this same research right now, and this is what I've learned today.

This IBM Developer Works article from August 2008 by Jorge Rasillo and Mike Burr shows how to do a Flex front-end / RESTful back-end app (examples in PHP and Groovy). Nice article. Anyway, here's the take away:

• Their PHP/Groovy code uses and expects PUT and DELETE.
• But the Flex code has to use POST, but sets the HTTP header X-Method-Override to DELETE (you can do the same for PUT I presume).
• Note that this is not the Proxy method discussed above.

// Flex doesn't know how to generate an HTTP DELETE.
// Fortunately, sMash/Zero will interpret an HTTP POST with
// an X-Method-Override: DELETE header as a DELETE.
deleteTodoHS.headers['X-Method-Override'] = 'DELETE';

What's happening here? the IBM web server intercepts and interprets the "POST with DELETE" as a DELETE.

So, I dug further and found this post and discussion with Don Box (one of the original SOAP guys). Apparently this is a fairly standard behavior since some browsers, etc. do not support PUT and DELETE, and is a work-around that has been around a while. Here's a snippet, but there's much more discussion.

"If I were building a GData client, I honestly wonder why I'd bother using DELETE and PUT methods at all given that X-HTTP-Method-Override is going to work in more cases/deployments."

My take away from this is that if your web side supports this X-Method-Override header, then you can use this approach. The Don Box comments make me think it's fairly well supported, but I've not confirmed that yet.

Another issue arises around being able to read the HTTP response headers. Again, from a blog post in 2007 by Nathan de Vries, we see this discussed. He followed up that blog post and discussion with his own comment:

"The only change on the web front is that newer versions of the Flash Player (certainly those supplied with the Flex 3 beta) now support the responseHeaders property on instances of HTTPStatusEvent."

I'm hoping that means it is a non-issue now.

As many have pointed out HTTPService is a bit simplistic and doesn't do all that you want to do. However, HTTPService is just sugar on top of the flash.net.* classes like URLLoader, URLRequest and URLRequestHeader. Using these you can assemble most HTTP requests.

When it comes to support for other methods than GET and POST the problem mostly lies in that some browsers (for example Safari) don't support these, and Flash Player relies on the browser for all it's networking.