Is it feasible to create a REST client with Flex?

Question

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?

Solution 1

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.

Solution 2

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.

Solution 3

There are definite shortcomings of Flex's ability to act as a pure RESTful client.

The comments below are from this blog:

The problem is HTTPService class has several major limitations:

1. Only GET and POST methods are supported out of the box (unless you use FDS and set useProxy attribute to true)
2. Not able to set request headers and there is no access to response headers. Therefore I am not able to access the response body in the case of an error.
3. It HTTPService gets a status code anything other 200, it consider an error. (event 201, ouch!!). The FaultEvent doesn’t provide information about the status code any response body. The Flex client will have no idea what went wrong.

Matt Raible also gave a nice presentation on REST with Rails, Grails, GWT and Flex that have some good references linked from it.

Whether it's feasible or not really depends on how much your willing to work around by proxying, etc.

Solution 4

The short answer is yes, you can do RESTful with Flex. You just have to work around the limitations of the Flash player (better with latest versions) and the containing browser's HTTP stack limitations.

We've been doing RESTful client development in Flex for more than a year after solving the basic HTTP request header and lack of PUT and DELETE via the rails-esque ?_method= approach. Tacky perhaps, but it gets the job done.

I noted some of the headers pain in an old blog post at http://verveguy.blogspot.com/2008/07/truth-about-flex-httpservice.html

Solution 5

Flex support for REST is weak at best. I spent a lot of time building a prototype so I know most of the issues. As mentioned previously , out of the box there is only support for GET and POST. At first glance it appears that you can use the proxy config in LiveCycle Data Services or Blaze to get support for PUT and DELETE. However, its a sham. The request coming from your Flex app will still be a POST. The proxy converts it to PUT or DELETE on the server side to trick your server side code. There are other issues as well. It's heard to believe that this is the best that Adobe could come up with. After my evaluation we decided to go in another direction.

View more solutions