Flash? Give it a REST

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.

The problems

• 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.

Comments

[Lionel]

It seems you are not the only one to gripe about this. In fact others have encountered and made solutions available for this:

http://lab.arc90.com/2008/03/25/flex-as3-library-restservice/

[Andrew Daniels]

You should read about REST anti-patterns. Cookies are one.

http://www.infoq.com/articles/rest-anti-patterns

[Malcolm Box]

Lionel: Indeed, anyone who tries to use Flash to access a real REST web service is in for the same pain. That's an interesting library you link to - alas it suffers from the pain of using sockets, which our experience tells us means it won't work for a lot of people sat behind corporate firewalls. Adobe have done a poor job of getting people to open port 843 so that sockets access works - and it's even hard to find a site you can use as a "checker" that the port is open/closed.

[Mark Doherty]

Hi Matt,

Here are some thoughts from my team mate Duane:
http://technoracle.blogspot.com/2010/07/soa-vs-rest-in-flash-player.html

Personally I'm all for it for the sake of productivity.

Mark

[Jason Brown]

On the whole I agree with what you are saying, but is the criticism the fact that Flash/Flex is REST unfriendly, or more that it has subpar HTTP support? Given Flash's background (remember Macromedia Director?) and it's intended audience (typically not hardcore, latter-day services folk), maybe the HTTP support is reasonable, though not optimal.

If we're going to fault Flash for not respecting cookies because that's a browser thing, should we expect it to respect Cache-Control headers and maintain a cache? I find that a more powerful tool in the HTTP-based RESTful toolkit.

[Malcolm Box]

Jason, thats a good point.  The criticism is that Flash is sub-par for implementing access to REST services over HTTP, which in my view makes it REST-unfriendly.  Flash is definitely an evolved product rather than a designed one, and it clearly started a long way from where it ended up.  Given that, I agree the HTTP support could be seen as adequate even if it doesnt do REST well.  The catch is that Adobe are now promoting it as a native web citizen - and native web citizens really need to support the fundamental architecture of the web.

Malcolm

[new york loan]

How do I make my flash game 2 players on one computer, and up to 4 online?