Yanni Mac wrote: > I am new to the whole RESTful idea and I am trying to use it in a new > version of my app. I might be totally missing the ball here, but this > is what I am trying to do. I have an application that is 95% read-only > to the public users, with a back end administration available to our > staff (basically a CMS). I want to create an API so that my users can > get an XML representation of a "widget" based on find criteria.. > something like this: > > http://myapp.com/widgets/123?height=1&weight=15.
Using a respond_to block on the show action of your widgets resource using: http://myapp.com/widgets/123.xml?height=1&weight=15 It's also possible to request the XML representation using the ACCEPTS HTTP header. > This would return XML for all widgets that had a height 1 and weight 15. > The users would also be able to create widgets (using REST) and some > client apps that run on the cron would have full CRUD access to the > widget resource. Trying not to fall into the trap that resources and models are one-to-one. Resources are independent of any back-end storage model. > At the same time I have a bunch of custom actions that should not be > RESTful and only available to users that are viewing the app with a Why shouldn't they be RESTful? Are you sure you understand what it means to be RESTful? > browser. I could add a bunch of logic to the "show" action, but I think Or add more resources to your application to manage the complexity in a RESTful approach. > it would get pretty messy and I like having the action name in the URL > for SEO purposes. By making the widget a resource, I can't use the > traditional "widgets/myaction" URL, because it tries to use "show" > instead of the action. I am guessing I can fiddle with the routes and > add my custom actions, but I am wondering if this is bad design? Should > I approach this a different way? I'm not exactly sure how having the action in the URL is any more friendly to SEO. I'm not SEO expert, but if that's the case it sounds like it's SEO that's broken. That's not how the traditional "static" web is designed. Uniform Resource Identifiers are all about about getting, posting, putting or deleting things. The "action" is not part of the URI. The action is dependent on the HTTP verb (GET, POST, PUT or DELETE) used in the request and is independent of the URI. The RESTful approach to dynamic web applications intends to bring this concept back. It's unfortunate that web browsers don't fully support this concept, but Rails does an adequate job remedying their shortcomings. What you need to keep in mind is that resources aren't controllers and they certainly aren't models. Yes there will likely be controllers and models supporting your resources, but they aren't the same thing. Check out these links for a lot more reliable explanation than I could ever provide myself: http://dablog.rubypal.com/2008/3/23/splitting-hairs-over-resource http://dablog.rubypal.com/2008/4/24/splitting-hairs-over-resource-part-2 -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
