With the recent Apple v Adobe spat over Flash, and the associated mudslinging as to who really is "open" and "web-centric", I thought it might be interesting to share some experiences in actually using Flash to build a front-end to a REST web service - in this case the Live Talkback servers.
Now a REST API is pretty much the definition of the "native Web" way of doing things, and everyone from Amazon to Yahoo via Google and Flickr have REST-style APIs these days. So you'd think that it would be a snap to use Flash to create a beautiful front end talking to those APIs.
You'd be wrong.
It turns out that getting Flash to talk to a REST API is surprisingly difficult, and ended up with us having to create several Flash-specific hacks in the server. Not a pretty sight at all.
- HTTP Methods: To do REST, you need to be able to send GET, POST, PUT and DELETE HTTP requests. Surely simple - any competent HTTP library has had method support for ever. Flash has the URLLoader class which should do the trick. Except that it doesn't support anything other than GET or POST when running in the browser. Fail.
- Go low-level: There's a workaround - use Flash sockets. This can be made to work, but runs into the morass of socket security policies served on port 843. Which is a port that lots and lots of places block. Fail
- Overload: OK, how about overloading POST? This is a common pattern to deal with libraries that can't do PUT/DELETE. So stick a new header in e.g. X-Method-Override: PUT, and then on the server side treat the POST as a PUT. Ah, but what's this? Flash refuses to put in new headers.
- Overload in the URL: OK, this can be made to work- http://www.example.com/resource?method=PUT. It's more than horrible, but hey - that's where Flash leaves you.
- Session management: Like most web services, we use session ids that are stored in cookies. Oh, but what's this? Flash refuses to send cookies. Fail again.
Can all these be worked around? Yes - and we've done it for the Live Talkback. But it rather takes the shine off Flash as a "web-centric" platform. Next time, we're going to be using straight AJAX/HTML.