Designing router & controllers in RESTful architecture

Question

Simple examples of controllers in a RESTful architecture suggest four actions per controller -- index, create, update, delete -- corresponding with the GET, POST, PUT, and DELETE. But beyond that I still find a dozen little decisions:

• Do you have a different controller for resource collections (example.com/things) than you do for an individual resource (example.com/things/123)?
• With individual resources, is it preferable to pass the id in as a parameter to the action, or set it as a member variable in the controller class?
• How do you go about URI routing? The old tried-and-true example.com/{controller}/{action} approach kind of falls apart.
• What about subordinate resources like example.com/user/123/things? Do you have to explicitly define every route for these or is there a way to write a good general rule?
• Do you differentiate between API requests and browser requests, or do you channel them through the same controller and/or controller methods?

Obviously, you could go about these things a dozen different ways, but I'd really like to not have to re-invent the wheel if others have hashed through the problem. I'm looking for any advice or maybe better some good tutorials that deal with these (and other related) practical issues in designing a RESTful mvc framework.

Answer 1

My controllers have methods Get(), Put(), Post(), Delete(), etc. I think using the "action terms" confuses the issue.

I always create a different controller for collections and single things. To me they are very different resources and I want the HTTP methods to do different things.

Routing I do differently than most frameworks. I don't match on the entire url, but on a segment by segment basis. It is similar to the way SubResources work in JAX-RS

For services that only have a small number of distinct resources then using regex style url pattern matching is fine. I just found it started to break down once you start dealing with hundreds of resources.