RESTful Flex Angst

Following on the previous post about issues encountered getting Rails and Flex to play together, we've now observed that certain popular browsers do not correctly interpret the HTTP specification for status codes on HTTP responses. Namely, IE 6 (haven't tested 7) treats any 200 status code other than 200 as an error. Perform an overloaded POST to a RESTful service in IE and get a 201 back, IE exposes a status of error to interested applications.

Why does this matter? When trying to do Flex integration with a Rails back-end, we are required to rely on Flex's callback mechanism to tell us if we get a result or a fault. Flex apparently, relies on the browser's plumbing to determine the success of the request. So, updating a RESTful resource via a Flex HTTPService for example appears as a failure at the Flex layer because IE tells the FVM that it got an error. This was the source of great angst for us because most of us test our Flex applications in Firefox.

The problem is further compounded by the fact that Flex doesn't expose any of the raw response data to us, simply a FaultEvent with little useful information (one of the dreaded stream errors actually). No headers, no body content, nothing. I've seen blog posts that hint at this being a limitation of the FVM's status as a lowest common denominator runtime, Flex included - some browsers don't expose headers to plug-ins so neither can the FVM.

When I find some time, I'm going to fire up the ActionScript Socket API and write an HTTP client that doesn't require overloaded POST, that exposes plumbing of the HTTP, and that allows *me* to determine what is or is not an error.

Alternatively, I've got a more simple tool in the works that will allow you to test HTTP methods of all sorts and status codes propagate back into the FVM.

In a future post I'll dig into some of the interesting behaviors we found examining these behaviors from the stand-alone player and how it does it's networking.