I’ve had Dave Thomas’ post about REST and the RADAR architecture open in one of my tabs since it was published a few weeks ago. I kept meaning to blog about it since it seemed very insightful with regards to the uses of REST as well as challenges ahead.

One issue that needs to be examined is that not all applications will follow a CRUD-style architecture so those will not map easily to some of the current Rails / REST services. I mention Rails only because the new REST routing and ActiveResource will enforce specific implementations which might or might not be the best choice for an application.

Dave talked a bit about RADAR (RESTful Application, Dumb-Ass Recipient) during some of the discussions last week at the Advanced Rails training. As an aside, if you ever get the chance to attend anything put on by the Pragmatic Studio, do so without hesitation. They really do an incredible job.

Ok, back to RADAR, the idea is simple, browsers are dumb and only understand two HTTP verbs (GET and POST). We can do things within URLs to help with the other verbs but really that’s just big hack. Why not just have your REST server separate? Then have the View application interact with that behind the scenes. The browser will be talking with the View, not knowing any better.

By doing this, I believe you will see an increase of small, individual apps which just have one job. They could be things like authentication or preferences or maybe even logging. This will increase your network traffic but for some things that won’t be a problem. The apps can be focused and reused by other View applications.

Technorati Tags:
rest, rubyonrails, RADAR

A little tempest in a teapot the past day or so has been the interview Twitter developer, Alex Payne did. In it, he somewhat calls out Rails for some of the performance issues Twitter has had. Of course, this causes some to jump on the Rails can’t scale bandwagon but I think that really misses the point.

It seems Twitter is doing upwards of 11K hits per second. That is a very impressive number for any site to handle especially when they didn’t build the site to scale from Day 1 which I think it the right thing to do.

DHH has chimed in with his thoughts and tried to clarify a couple of points. In doing so, I think the original post came off a bit defensive but if you read thru the comments you’ll see a good back and forth between Alex and DHH. Those should be raised to the level of a post. In his comment, Alex ends with: We’re happiest scaling on Rails. I think that should be what the focus is, not on the Twitter folks slamming Rails and wishing they had used something else.

More thoughts from Rafe and Kellan. Kellan ends with:

You’ll never build a successful site if you build to scale from day 1, scaling is always a catch up game, but it’s the best game there is.

Another mantra to live by because if you have scaling issues, you are generally doing something right.

Technorati Tags:
rubyonrails, scability, twitter