Hacker News Reader

Comment by joshbuddy | Hacker News Reader

Essentially, it let's you take something like

  before '/blog/:id' do
    @blog = Blog.get(params[:id])
  end
  
  get '/blog/:id' do
    @blog
  end
  
  put '/blog/:id' do
    @blog.update_attributes(params)
  end

and turn it into

  path 'blog' do
    var do |id|
      @blog = Blog.get(id)
      get { halt @blog }
      put { @blog.update(request.params); halt :ok}
    end
  end

I feel this is DRY'er than the Sinatra representation. It also has nice integration with Rack itself. The implementation is very simple, easy to get into.

View on HN

Here's the same in Camping, using plain Ruby:

    class Blog < R '/blog/(\d+)'
      def service(id) @blog = Blog.get(id); super end
      def get(id)     render :blog end
      def put(id)     @blog.update_attributes(@input) end
    end

What I discovered recently when doing a new Rails 3 app was that the RESTful CRUD stuff is all boilerplate. This is true about Sinatra apps, too: Every GET, POST, PUT and DELETE are just wrappers around find, create update and destroy. I used Rabl for generating JSON, so it was possible to write a single serialization for all objects. So why not just boil everything down to the minimal code required?

Something like this:

    handle '/blog'

That's it. This makes some assumptions:

* That /blog maps to a class Blog which it can load and save. * That you either use "fat models" (with callbacks that munge data and perform actions when data changes) or external observers (like ActiveRecord's observers). * That the model supports all four CRUD actions.

When you want additional verbs:

    handle 'GET /blog/search' do
      MySearchEngine.search(params[:q])
    end

Or object-specific ones:

    handle 'GET /blog/:id/search' do |blog|
      MySearchEngine.search(params[:q], :blog_id => blog.id)
    end

In fact, aside from extra verbs, you could get away with no code at all, since you could introspect the database layer to discover which classes are mappable.

My app is a JavaScript-based single-page HTML5 web application using Backbone, so there is almost no server-side frontend code, meaning my app is basically a server-side database anyway.

I wrote something like this a while back: https://github.com/nakajima/sinatras-hat It's no longer maintained, but it was fun to see how many assumptions I could jam into one framework.

That's pretty cool!

The same in Cuba (http://cuba.is):

    Cuba.define do
      on "blog/:id" do |id|
        blog = Blog.get(id)

        on(get) { res.write blog }
        on(put) { blog.update(req.params); res.write :ok }
      end
    end

These all seem like good ideas in their own way. I say "it's great that we have all these useful ways of doing similar things!". Choose whatever best fits your application. I really like that this type of stuff is catching on over Rails.

Reply on news.ycombinator.com