The Artima Developer Community
Sponsored Link

Ruby Buzz Forum
REST Leading To Rails

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page


Posts: 201
Nickname: cfis
Registered: Mar, 2006

Charlie Savage
REST Leading To Rails Posted: Mar 22, 2006 2:52 AM
Reply to this message Reply

This post originated from an RSS feed registered with Ruby Buzz by .
Original Post: REST Leading To Rails
Feed Title: cfis
Feed URL: http://cfis.savagexi.com/articles.rss
Feed Description: Charlie's Blog
Latest Ruby Buzz Posts
Latest Ruby Buzz Posts by
Latest Posts From cfis

Advertisement

From 2000 to 2004, Peter and I drove the development of GE Smallworld’s Internet Application Suite which made is possible for customers to put their complex-GIS applications onto the Web.

What we built was in many ways similar to Rails. It used a dynamic language called Magik (not much different than Ruby, maybe I’ll post about it one day), had an ORM layer, had controllers (we called them services), had the concept of layouts, partials, pages, etc. I suppose it shouldn’t be that surprising since both frameworks were designed to solve similar problems - although ours heavily focused on GIS applications. Anyway, I find it fascinating to compare and contrast what we did versus what Rails does. Much is worse, some is better.

We also learned a whole lot about the Web and its triumvirate of technologies - URIs, HTML and HTTP. At the beginning, our URIs were on the ugly side and we thought REST was something precious you squeezed into the nooks of an 80 hour work week. And then we succumbed to the chimera of Web Services and soon became experts on all things Web Services - name the spec and we knew it cold. WSDL? XML Schema? SOAP? No problem. And I don’t mean we knew how to use it - I mean we knew how to implement it starting with just a lowly XML parser [No - were are not masochists, we had to because of the environment in which we worked].

By 2002 we had come to our senses - Web Services were a great idea but SOAP sure wasn’t - not to mention XML Schema (for fun go look up substitution groups and wonder why). We found the RESTafarian religion thanks to the writings of Roy Fielding (you really should read his dissertation!), Paul Prescod, Mark Baker, etc. After lots of internal discussion and debate (or was that shouting matches) we made the decision that REST was the one true way for web apps and that’s where we were taking the product. And we never looked back.

Now its three years later and we’ve both moved on to other jobs/ventures. By coincidence we both recently got back into web development using Rails. Surveying the web development landscape again - its remarkable to see the WS* versus REST debate still raging. REST is so much better suited for building web applications, as very many smart people have explained over and over and over and (yeah I’ll stop now), that is amazing there is any doubt left. However, I have a nice dream that the debate is almost over because the Atom publishing protocol, Rails and PHP (don’t hold me to the PHP claim since I’ve never used it) are driving a stake into the WS* heart.

Which brings us back, in our own tortuous way, to Rails. Rails is fun to use. Rails is productive. And Rails is fully RESTFUL…or not. Fortunately, its actually not that far off but does have some warts as Peter did a great job explaining a couple months ago. The summary is that it falls short it two places. First the inclusion of actions in URLs and second in HTTP content-negotiation. And that sets the stages for my next couple of posts. Till then….

Read: REST Leading To Rails

Topic: Ruby Hacking Guide Translation Project Started Previous Topic   Next Topic Topic: The adventures of scaling, Stage 2

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use