We’ve built the world’s most beautiful web API and have done our best to comply with all constraints for representational state transfers. It’s been in production for quite some time and used by a few clients, including apps for both iPhones and Androids.
As a next step, we want to make our own (popular) flash application an official API client and deprecate all the custom-made feeds we’ve created for it in the past. Sounds awesome. Turns out, it is not awesome. When hosted in a browser, Flash has several limitations that make it very difficult to use a RESTful web service correctly.
Setting HTTP Headers is unreliable
Standard HTTP Headers cannot be used reliably because their behavior strongly depends on the combination of browser and flash player version. Example: Let’s assume the API supports different request and response formats via
Accept headers. Setting the request’s
Accept header to
application/json will work fine in Chrome for Mac 11.0.696.57 with Flash Player 10.2.154.27 but Firefox for Mac 4.0 with Flash Player 10.1.102.64 will just send whatever
Accept header the browser sends with all requests (in this case
Custom HTTP Headers only work for POSTs
Due to a bug in the Flash Player, custom HTTP headers cannot be sent with
GETs. This is still open at the moment, and once it is fixed, it will be another thing that strongly depends on the user’s flash player version.
Methods other than GET and POST are not supported
Although this seems to be a browser limitation rather than a flash player limitation, only HTTP
POSTs are supported (tracked here). Workarounds include the (in)famous
X-Method-Override header, and the
_method url parameter with all its fans in the ruby community.
In addition, apparently sometimes
POSTs are turned into
GETs under specific circumstances.
Problems with HTTP Response
There are several issues regarding the HTTP response. HTTP response headers are hidden (bug), HTTP status codes cannot be retrieved (not supported), and the body cannot be accessed for responses with status codes other than 200 (feature).
Although all of the above sound horrific, maybe none of it will be an actual problem for our endeavor. We’ll do with
POSTs, move our token from the custom HTTP header to the URL and mitigate the response format issue by defining a default response format (e.g.
- Can AS3 do REST, or not?
- The Truth about Flex HTTPService
- Stackoverflow: Is it feasible to create a REST client with Flex?
Disclaimer: I’m not a flash developer (and don’t want to be one :) but I see the team that is trying to use our API run into these issues.