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 Content-Type and 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 text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8).

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 GETs and 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 GETs and 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. application/json).

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.