I like REST, it generally makes sense and is pretty easy to follow.
Where I'm having trouble though is when it comes to the point where you need to update multiple records.
Say for instance you have an email application, which is RESTful.
Now lets say you go to your inbox and select 5 emails and you want to mark them all as read.
It would be easy enough to create a custom action that would process this kind of request, but is there a good way to do it while maintaining REST?
I asked this very question about a week ago and didn’t get a definitive answer. The consensus was that I was missing a model somewhere. That answer didn’t really work for me (since I was RESTifying a production app and couldn’t change it too extremely). So I have routes like:
map.resources :emails, :collection => { :archive => :post, :destroy => :delete }
and then, in your EmailsController#destroy, you need to handle multiple email ids. It’s a hack, but it can work.
ed
Thanks for the reference to the previous discussion and your choice of solution.
I'm designing a new app luckily, and I'm still in the "making pieces fit together" stage of things. So I have a lot more liberty in my data modeling.
I think I understand well enough to try and put something together.
I suppose I just need to treat the "mark multiple emails as read" action as a seperate model. Then you can restfully create batch requests.
Seems like a round about way to do it, but maybe I just need to let the idea sink in better...
Short a specific answer to that very common problem I would be disinclined to agree that you’re missing a model to represent a collection of accounts. If it’s clean and clear and there’s a convention there it should’ve been easy to get an answer to your very simple and fair question about updating multiple records.
I still tend to agree.
It might be great to wrap your transactions in a model of some sort if you need to do auditing or other things, but most apps don't need the extra overhead.
There are certainly situations where the "you missed a model" answer is probably quite true, as DHH did when he introduced a lot of this stuff. In that case it did make sense to squeeze another model in the middle to solve the problem.
I don't necessarily think that the sort of processing we are talking about fits into that same notion though. Or at least I remain unconvinced.
That doesn't mean that I have some shining light or better way either, unfortunately. It just means I haven't figured this out yet (and I suspect I'm not the only one).
You don't necessarily need a separate model to handle operations on multiple records.
I've got a few places in my app where I need to perform an action on a group of related records, and the best way I've found is to use class methods. You could simply define a Message.mark_as_read(message_ids) method in your message class. Class methods are useful when you need to do table-level (as opposed to row-level) operations. That way, you're keeping all the logic for marking multiple messages as read in the model, where it belongs, and your controller can simply have an 'archive' action to call it and pass it the array of message_ids.
That sounds entirely logical to me.
I would agree that using the class method is a good way to implement it too.
The problem is that, by my understanding, you would be breaking out of the REST paradigm. REST aims to make it such that the only actions are create, read, update and delete.
As per DHH in the <a href="http://weblog.rubyonrails.org/2007/1/19/ rails-1-2-rest-admiration-http-lovefest-and-utf-8-celebrations">1.2 announcement</a> "Then start thinking about how your application could become more RESTful. How you too can transform that 15-action controller into 2-3 new controllers each embracing a single resource with CRUDing love."
REST uses nouns, not verbs. So having other actions than CRUD (which can use the same noun, at least in theory, by using HTML PUT, GET, DELETE) is against the RESTful rules.
I want to be able to click a button and have it submit several requests to the same action. That is what a batch controller or an external application would do. There just doesn't seem to be a good, direct way to do this (that I know of) within a webpage...
I had a similar problem…
I wanted an action to connect a product to it’s categories…
So the web user can pick several categories from a list and assign it to the current product
This means you have two different model classes, one single product and several categories that should be connected by a m:n relationship. how could you model something like that in crud?
I find the idea of having a ProductCategoriesController a little awkward 
Having an action set_categories inside the ProductController that accepts a list of categories seems logical but doesn’t fit into crud either.
My personal opinion is that REST has it’s limits and is no replacement for bulky controller actions and routes sigh
Just curious what you guys think of this:
Why not create a transient (no db table) model named EmailBatch or whatever. Conceptually it would always exist and it's id is always 1 so you'd always do PUT/update operations. You simply initialize it with whatever group of emails you need to deal with at any given moment.
Then have an EmailBatchesController with routes like the following.
/inbox/email_batch/1;read
or whatever.
Did that make sense?
Tim
oops sorry... that route is:
/inbox/37/email_batch/1;read
or whatever:-) Tim
Seems like a lot of bending over backwards for a new, shiny concept like REST when a simple "each" loop and set of checkboxes works fine.
I predict that, like so many other design fads, REST will be a "remember that thing?" 10 years from now. Don't kill yourself for it. Get as close as you can.
-Nate
The thing that's helped me the most in refactoring to REST is understanding what Nouns need to be accessible externally. My RESTful controllers support the basic CRUD operations, and then, as needed have additional operations for the in-browser user experience. In this case, I'd say that "mark selected emails read" is the sort of thing that a user interacting with the application via a web browser would like to have, but it probably doesn't matter to an XML REST client consuming your site externally. So, in that case, I don't mind having a controller with 9-12 actions where the extra actions support the user experience.
If you're finding that you want to view the mailbox externally, check off messages, and mark them as read over REST, the client can do some of the lifting for you, in which case that client will loop over the IDs and make separate PUT calls to change the has_been_read status from false to true.
I don't know if I'd go so far as to suggest that REST will wind up completely forgotten... there will always be certain cases where we want machine-to-machine communication.
However, I do smell a little bit of shiny-new-thing-itis... I would throw out the question: how many people playing (struggling?) with RESTful rails actually have a machine-to-machine use case? Are most people adding REST services "just in case"?
b
PS: My current project is currently fleshing out an application with very heavy REST usage, so I don't mean to come off as a luddite here.
Nate Wiger wrote:
Just a point of clarification of the concept of REST (at least the one that is inside my head).
REST .NEQ. CRUD
REST uses verbs acting on nouns.
Simple entities with trivial life-cycles can be handled with CRUD. They are either there or they are not. In business analysis terms, these are usually classifiers or look-ups (e.g. sales area, message type,...)
More interesting entities have a richer life-cycle typically marked with a status field. (e.g. Mail message={Unread,Read,Archived}, WorksOrder = {Booked,Scheduled,In Progress, Completed,Billed} )
Now moving from one status to another is a life-cycle event and often there is extra data involved. So the 'Read' event for the mail-message moves it from 'Unread' to 'Read' and may involve populating the read_date column. The 'StartWork' event for the WorksOrder moves it from the 'Scheduled' to 'In progress' state and may involve populating the start_date and also adding work-queue information to other parts of the data model.
This concept is very well documented in its variants as 'finite state machine', 'state transition diagram','state machine','state engine','life-cycle model',.....
One of the goals of REST is to surface your state-engine events as verbs on the underlying nouns.
As he climbs wearily down from his soap-box, "Oh yeah, it only works for a single entity life-cycle, so class methods are good for small batches".
ChrisR
One of the goals of REST is to surface your state-engine events as verbs on the underlying nouns.
Yes. I agree, but I think the 'state machine' description is useful.
One of the goals of REST is to surface your state-engine events as verbs on the underlying nouns.
I agree, but having custom verbs is also not good. One of the main goals of the REST model is consistancy across models. I think a lot of this type of state-to-state transition can be covered with simple updates. If you need more data than that you may need a has_many through sort of thing.
As he climbs wearily down from his soap-box, "Oh yeah, it only works for a single entity life-cycle, so class methods are good for small batches".
This is definately the case. I think I have the pieces together in my mind now. All single model updates (the stuff that would be accessible both externally and internally) probably ought to be restful. If you need to do stuff like batch processing you can add extra options/actions, and it won't break REST.
Thats because when you add these external options for internal use you are really building a client, which just happens to reside on the server due to the nature of the web. So, go wild but keep it to yourself. Which, I think is what Jared was suggesting.
As for Nate and Ben. I think that REST is useful and there is a growing need for machine-to- machine interaction. BUT, I think people are misunderstanding what that entails and going overboard or "bending over backwards" to try and fit round pegs into square holes.
Lots of discussion, so a summary of my thoughts:
Use/Expose a RESTful interface to each of your models, to handle all the requests to manipulate single objects. More complex and batched commands can exist outside the REST model, in order to provide client-type functionality. These complex functions need not be exposed (each client should provide their own utility functions), and for consistancy they should use the REST methods to actually do the meat of the work (therefore decoupling/drying up the actual model manipulation from other complex logic).
Hopefully that makes some sense, I at least feel like I have a much firmer grasp of what I'm up against. I think it may take me a bit more time to really put it down in a succinct, elequent manner...
So what's the point?
REST is good for simple stuff ... and that's it???
just another hype/buzzword?
my current summary (with the 'mark emails as read' example):
- I don't think it makes sense to iterate several emails in the
browser to mark them unread (c'mon, one http request for each mail,
you gotta be kidding 
- having additional nouns/verbs that affect more than one model type or instance seems not to fit into REST
- I don't think a 'EmailBatch' can necessarily be seen as a model
- having an extra so called 'batch-processor' for every little operation consisting of more than one item or whatever sounds ridicuous IMHO
- it seems that most people think REST ist cool but they all just struggle with it. so REST is only useful for the most simple of cases (create, read, update, delete) but gives you a headache if you need more...
true?
<...>
- it seems that most people think REST ist cool but they all just struggle with it. so REST is only useful for the most simple of cases (create, read, update, delete) but gives you a headache if you need more...
true?
False
Regards, Rimantas
just another hype/buzzword?
I think it is useful for structuring server side things, it just doesn't cover all the needs of a client.
- I don't think it makes sense to iterate several emails in the browser to mark them unread (c'mon, one http request for each mail, you gotta be kidding
I could go either way. Iterating over them doesn't really seem intolerable to me, and treating them as individual is cleaner and more regular than somehow modifying multiples.
- having additional nouns/verbs that affect more than one model type or instance seems not to fit into REST
I would still say this is the case, I'm not sure what you were saying about them though. I think it is important to be consistant so it would be better to keep it limited to exposed CRUD operations when possible.
- I don't think a 'EmailBatch' can necessarily be seen as a model
I agree here. I think it would be terrible case of premature extraction, but unfortunately a lot of people seem to be trying to head down that road. Or at least to use "find an extra model" as an easy way to answer a hard question.
- having an extra so called 'batch-processor' for every little operation consisting of more than one item or whatever sounds ridicuous IMHO
I agree, hence why I feel a request per item probably makes more sense.
- it seems that most people think REST ist cool but they all just struggle with it. so REST is only useful for the most simple of cases (create, read, update, delete) but gives you a headache if you need more...
true?
I don't think that it should be disregarded simply because it is hard or misunderstood. I think it is good to shift the focus to a resource driven architecture, as this is often a better/cleaner solution. I just think it is folly to try and fit everything within this context, there are some things that are better off being outside this clean little package. The kinds of things that an independant client would do to aide user interaction still need to be done, and I feel that it is in this area that REST alone falls short.
- I don’t think it makes sense to iterate several emails in the browser to mark them unread (c’mon, one http request for each mail,
you gotta be kidding
Yes, separate HTTP requests for the bulk actions seems a bit overkill to me. My solution for these multi-item actions was to just bastardize the REST methodologies and allow the method to be passed multiple ids in the query string. I then iterate over then in the code.
- I don’t think a ‘EmailBatch’ can necessarily be seen as a model
I agree here. I think it would be terrible case of premature extraction, but unfortunately a lot of people seem to be trying to head down that road. Or at least to use “find an extra model” as an easy way to answer a hard question.
I also agree. For some cases, a new model makes sense, but for many things (like EmailBatch) it seems unnecessary. So great, you’re following the REST ideals but now your breaking other good coding methods and making things generally more complicated! For me, I think it will just take time to understand the intricacies of REST and the best ways to handle the issue that arise when coding under the inherent constraints.
-ed
I grew up with 8 bit computers where people cared about resources. creating probably houndreds of http(s) requests to mark 250 spam email for deletion is just so horrible that I must stop breathing... :-((