Tech Blog

We have been working hard to implement an XML-based REST-style API for Floorplanner and some of our partners are using it already to access their users and plans. We now have started to use this API ourselves.

The Floorplanner Flash application communicates with our servers to load and save projects and designs. The backend for this functionality used to be written in PHP. Eliminating this PHP application simplifies our server setup, eases development and reduces our maintenance burden. To rewrite this functionality in Rails, we decided to eat our own dogfood and use the REST API to load and save designs. Why reinvent the wheel?

However, while implementing the changes it the Flash application, we found that it did not work out of the box, because of some limitations in ActionScript. Note that we still use ActionScript 2, so some of these issues may not be relevant for ActionScript 3. In this post, we will detail what these issues are and how we overcame them.

Using a separate format

Our REST API uses the XML format supplied by Rails. Because we had to make some changes to make it work from ActionScript, we decided to add a distinct format that we could implement differently without altering the behavior of the default XML API. Adding a new format, called “flash” can be done in Rails by adding a MIME alias to your environment:

Mime::Type.register_alias "application/xml", :flash

Now we can send different responses based on this format:

respond_to do |format|
  format.xml   { ... } # default API behavior
  format.flash { ... } # do something different
end

HTTP status codes

REST APIs use HTTP status codes to return whether a call succeeded, and if not, why. Flash however uses the browser to perform HTTP requests. The browser only returns something to Flash if the request was successful. So, if an error code is used if a request failed together with some error messages, these error messages will not be delivered to Flash and cannot be displayed to the user. We resolved this by always sending the HTTP OK status.

respond_to do |format|
  format.xml   { render :xml => @project.errors, :status => 422 }
  format.flash { render :xml => XML.failure(@project.errors, 422) }
end

Our XML.failure method will return something like:

<failure status="422">
  <error on="name">A project should have a name!</error>
</failure>

Note that other HTTP success statuses than 200 work in Safari and Firefox, but not in Internet Explorer. So, never return a 201 (:created), because Internet Explorer will not send the result to Flash!

PUT and DELETE requests

REST-style APIs use HTTP PUT requests to alter objects and DELETE requests to destroy objects. Most browsers do not support these request type. It is not supported by ActionScript either, because Flash uses the browser to send the request.

To overcome this problem, these types of requests can be simulated in Rails by sending a _method parameter along with a POST request. Unfortunately, this does not work when calling the REST API. The POST request body cannot be used to send additional variables, because it is used for the XML payload.

We solved this issue by creating additional routes for POST requests to the update and destroy actions of our resource controllers. Our routes.rb file now looks like this:

  map.resources :projects, :member => { :update => :post, :destroy => :post }

These routes route to exactly the same methods as the default REST actions (ProjectsController#update and ProjectsController#destroy), so no additional code is needed. The following calls are now equivalent:

PUT    /projects/123.xml
POST   /projects/123/update.xml
POST   /projects/123/update.flash

DELETE /projects/123.xml
POST   /projects/123/destroy.xml
POST   /projects/123/destroy.flash

The result

It requires some stretching of the pure REST principles, but doing so is worth it: we can now reuse the code we use for our API to handle Flash application calls and we can eliminate the PHP backend.

This might be a little off topic, but I found it interesting enough to share it with you all. It’s about the future of capitalism: Constructive Capitalism through the principles of Renewal, Peace, Equity, Meaning and Democracy. 

It’s a presentation Umair Haque gave at Daytona Sessions last month. Umair Haque is Director of the Havas Media Lab, a new kind of strategic advisor that helps investors, entrepreneurs, and firms experiment with, craft, and drive radical management, business model, and strategic innovation. Daytona Sessions is a recurring conference about the future of business and Internet held in Stockholm, Sweden. 

Enjoy!

Ted Patrick (Senior Manager Developer Communities at Adobe Systems) has posted an interesting article about the first milestone of the Eclipse E4 project.

It seems that the SWT project has added compilation support for SWF from JAVA. Write your app in JAVA and publish as SWF to Flash Player. The cool part is that you get full JAVA development in Eclipse with all debugging and tooling but you get a SWF file on publish. 

We’re using Flex Builder for our Flex/AS3 stuff, but this could become a very interesting option since the JAVA development in Eclipse is a lot more sophisticated than Flex Builder at the moment.

Gert-Jan is on the left side and Jaap on the right.

Nico is on the left side and Willem on the right.

There is a lot of hype these day about being in “the cloud”. However, “the cloud” seems to mean a lot of different things. Tim O’Reilly sees three types of cloud computing.  His first type, utility computing, is the type I’m talking about here. 

Utility computing. Amazon’s success in providing virtual machine instances, storage, and computation at pay-as-you-go utility pricing was the breakthrough in this category, and now everyone wants to play. Developers, not end-users, are the target of this kind of cloud computing.

Launched in July 2002, Amazon Web Services provide online services for other web sites or client-side applications. Each individual product is interesting by itself, but all the services together made it just the solution we were looking for. In this and coming posts I will talk about our experiences with Amazon’s version of “the cloud”. The first service we started to use was Elastic Cloud Computing (EC2).

Each day more than 2000 users from all over the world register at Floorplanner.com. At this moment we have over 800.000 registered users in our database. A lot of these users visit the site on a regular basis, which generates a lot of traffic. To meet this demand, we had a couple of dedicated servers running. When the demand rised above a certain level, we’d add a new one to spread the load. As logical as it might sound, it is far from ideal.

It takes a lot of time to install, configure and maintain a server. Precious time you can’t spend on the development of your product. It doesn’t scale fast. For example: when you are featured on a big site that generates a lot of additional traffic, your servers will probably have a very hard time (or crash) and there is nothing you can do about it. Buying additional servers takes too much time. Another thing about buying servers is that it’s an investment you have to finance up front. You have to pay the full price for it, but in the beginning you’ll only use a small part of it’s capacities. Once you’ve spend the money on a server, you can’t spend it on anything else. And maybe the biggest issue we had with dedicated servers was that it is hardware, and hardware gets old very fast. After a while you’re stuck with an outdated server, that you (a) won’t replace because “it’s still doing something” or (b) costs time (= money) to migrate to another server. This means a higher risk for failure, or just more work.   

Now with the EC2 service life has gotten better. Sure, we still had to install everything on the virtual instance, but only the first time. Once you’ve done this, you can add additional instances with a click of a button (based on an image of the first instance). When traffic spikes you can add instances within minutes instead of days. The pay-as-you-go model keeps us from financing every server up front. And because it’s a virtual server, we don’t have to think about the hardware anymore. Just deploy it and get on with the fun stuff!