Just finished a month long conversion of a Flex project from consuming a PHP backend to RESTified Rails backend, and it was a new experience for me. Needless to say, some of the things in Rails are really great, but there’s a few gotchas that still show up in consuming responses from Rails using REST.
Rails for the most part is simply a framework that exists on top of Ruby, and generally is used as exposure for data (scaffolding is the term for generating a representation of a database table with generalized methods to get and set data against it). I’m simplifying, but that’s what I do.
REST is a type of agreement between the client and server applications which denotes a common communication protocol. I’m more apt to recommend something other than REST for Flash since there are some serious shortcomings in how the flash player communicates with the server. These are very obvious once you’ve built an app.
The general methods are very appealing at first glance — a common language for common tasks is pretty, but in usage the browsers and flash need to be able to work with these new protocols (REST uses a lot of assumptions about the HTTP methods being respected and utilized by the browser, and very often this is not the case). In point, at one point the Rails app was sending back 201 success codes with returned data, but the flash player didn’t recognize this as a success method and effectively did not send the returned data to the Flex app. Switching to a 200 method on the success worked fine. Took a while to figure that out!
Another odd situation is that very often Rails RESTified uses all manner of return codes that are often not recognized by the Flash player as good codes to get, so until the flash player uses these codes correctly and as HTTP intended you’ll be doing all kinds of work arounds to wrangle the app. But it can be done, it just can’t be assumed that it’ll be seamless (the project took twice as long to finish because of these issues).
In this post I’ll add some specific examples of solutions to odd behaviours:
In rails they’ve built in a workaround to the limitation that most current browsers face with regards to GET, PUT, DELETE, and POST requests when working with a Rails application. Only two of those methods are supported (GET and POST) so the engineers of the Rails system built in an interpretation variable to enable the other methods under a standard POST command. To send a DELETE command, you use a POST with a variable named “_method” and make it equal to the type of request.
Each method has a meaning:
GET is to request data
POST is to create data
PUT is to update data
DELETE is to delete data
In Flex, to make the call you would use this method:
var params:URLVariables = new URLVariables();
var loader:URLLoader = new URLLoader();
loader.addEventListener(Event.COMPLETE, resultHandler);
loader.addEventListener(IOErrorEvent.IO_ERROR, errorHandler);
loader.addEventListener(HTTPStatusEvent.HTTP_STATUS,httpStatusHandler);
request.url = http://www.wabbit.ca;
// If a data request
request.method = URLRequestMethod.GET;
// If sending data for creating a new record
request.method = URLRequestMethod.POST;
// If sending an id to delete a record
request.method = URLRequestMethod.POST;
request.data._method = “DELETE”;
// If sending an id and data to update a record
request.method = URLRequestMethod.POST;
request.data._method = “PUT”;
// add your data objects to the request.data object
request.data["item[index]“] = item[index]; // very often Rails will expect your data to populate in the form of an array and possibly other formats of the same method.
loader.load(request);
In general the HTTP headers you may receive from Rails are not your standard responses, so you’ll have to work with your Rails developer to ensure that what is being sent to Flex/Flash can be handled by the Flash player (or browser in some cases).
Also, any 20x series event is considered a ’500 server error’ event except for the base 200 event.
