0

I'm pretty new to Rails 3 and I'm trying to understand the advantage of designing an application in a RESTful way. I don't need an API/Web Service. Don't need XML or JSON.

The application I'm building uses no CRUD at all. It is an app that gathers trade data via a socket connection and displays it to a user in many different ways.

I would like to visualize trades in different ways such as:

  • Most recent
  • Highest Yielding
  • Trades by State
  • Most active trades
  • Million dollar trades
  • Trades that are general obligation bonds
  • etc…

In the "Rails way" it seems that I would have a very overloaded index action. Or I could go against convention and just create methods in the trades controller like most_recent, highest_yielding, most_active, etc. But that seems to go against the whole philosophy of designing an app in Rails 3.

It just seems like the idea behind a RESTful approach in Rails is based around CRUD and falls short when CRUD isn't involved. Is there really an advantage to designing your app to be "RESTful" besides following a convention? I'm not really seeing the advantage here.

Plus, if I ever do need an API, I would imagine that it would be much better to design an API with an API in mind. My API wouldn't be a direct 1 to 1 match of my website which is built for human consumption vs a machine.

I'd appreciate any insight on this. Maybe I'm missing something here?

Dan
  • 119
  • 8
  • CRUD is involved - all of those ways you listed to "visualize" trades are included in the 'R' part of CRUD, which stands for "read". – Zachary Wright Apr 23 '11 at 22:38
  • I guess of better way of asking the question would have been: What's the best way to handle resources which are "read" heavy. Do they all point back to a single index action with many IF statements? That just seems messy. That's more what I'm getting at. – Dan Apr 23 '11 at 22:51

3 Answers3

1

CRUD is actually involved when resources are involved. And since virtually every application has resources CRUD can be involved and is usually(if you ask me), the best way to do it.

The idea is that a resource has certain actions. You view a resource, you edit it, you delete it and some more. The methods like most_recent(or scope for this one) should be used in models and not controllers. Then, if you need to use that collection, you would just call something like :

@recent_posts = Post.most_recent

in your controller. Your controllers should not have much code, actually no business logic at all.

RESTful is very nice because it handles resources naturally. A controller should actually be handling a resource. If you think that something can be edited or created, then it should be handled by a controller.

Generally, i highly suggest that you take a deeper look and you will definitely see the advantages on your own.

Spyros
  • 41,000
  • 23
  • 80
  • 121
1

I have idea how to do it. Code is not tested, I just wrote it without running.

Controller:

# trades_controller.rb
def index
  # all scopes defined in model will be allowed here
  # not good idea if you don't want it
  if Trade.scopes.has_key?(params[:scope].to_sym)
    @trades = Trade.send(:params[:scope]) 
  else
    # render error or what you want
  end
end

Model

# trade.rb
  scope :most_recent, order(:created_at)
  # more scopes

View

# index.html.erb
link_to 'Most recent', trades_path(:scope => 'most_recent')
retro
  • 3,497
  • 18
  • 37
  • That makes sense. I guess I could decide what view to render based on the scope as well. – Dan Apr 23 '11 at 22:54
0

Your design should always take into account the requirements of your application first and the philosophy of the framework second.

If the philosophy doesn't fit your requirements or what you believe is the best way to develop your application then either ignore it, or, if the framework makes it too difficult for you to build like you think you should (which isn't the case in Rails imho), switch to another framework.

All of that doesn't have much to do with REST. For more info on why REST is considered a good idea (for some, not all, things), see the following SO Q&A's: Why would one use REST instead of Web services and What exactly is RESTful programming.

Community
  • 1
  • 1
Elad
  • 3,085
  • 2
  • 18
  • 17