REST + less weekend while Camping

Sep 23, 2008

In the wee hours while visiting my family this weekend I decided to take a look at a few technologies;

• REST
• RestStop
• Actionscript 3 URLStream

I started out with RestStop’s blog.rb as a starting point, and modified it as an event recorder. It worked like a charm out of the box. From there I wrote a quick Flash interface to POST data to each controllers create method. BOOM, Ka-POW, Problems… I was getting a little unexpected funk from the way Flash was handling HTTP status codes. IOErrorEvent’s were being fired, babies cried, etc. So far my observations have shown that URLStream & URLLoader classes do a funky dance when they receive 3xx series status. At a later date I would like to investigate further to see if the 3xx status is the cause of the IOErrorEvent. Ultimately the classes only report the final http status and none of the intermediary status changes. I decided to look around a little on Google into what I thought to be a fairly standardized protocol. Turns out REST is less of a protocol and more of a methodology. Regardless of what you call it I’d still like to work from a common community shared standard, at least when it comes to HTTP status codes. In that search I found the table below buried in the article How to Create a REST Protocol. It was great my first resource that seemed to clearly define some constraints in what otherwise looked like the Wild West of RESTful web services.

I pulled up the descriptions for each of the status codes, and made a short comment in my Camping app.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<code>
# Event GET      200,301,410
# Event PUT      200,301,400,410
# Event DELETE   200,204
# Events GET     200,301
# Events POST    201,400
#
# 200 - OK
# 201 - Created
# 204 - No Content
# 301 - Moved Permanently
# 400 - Bad Request
# 410 - Gone
</code>

Now I want to take the previous table a little bit further to map out each of the states.

tags: [ ruby ]