I’m trying to allow users to vote a record up/down with Ajax. I’m using the vote_fu plugin for the voting functionality, and everything works fine without Ajax. I’m now trying to figure out the best way to implement the asynchronous functionality with unobtrusive javascript.
What I’m doing now is having two buttons, “Up” and “Down”, such that when you click either one, a request is made to votes_controller and the create or update action, depending on if the user had already submitted a vote on that record before. The params submitted would be the record_id as well as the value of the vote.
With Ajax, how should I handle the case where a user enters a page to vote without having voted on the record before? Specifically, the links would go to the votes#create in the beginning, but after that first submission, the links should switch to votes#update.
Is there a standard way to take care of this? I was thinking about just adding an extra check in the “create” method such that it would act like “update” if it found a record for the user_id, voteable_id pair, but this seemed kind of clumsy and not fully RESTful.
Thanks,
Eric
There are several techniques/patterns commonly used:
1) When your erb creates the page, you can supply a parameter to the JS script that is a part of the page. The parameter will be the “voting_url” it will be either votes/new or votes/123 depending on whether a create or update operation should be used.
2) You could use a “procedure call” as opposed to a rest call. The procedure/action would be “change_vote” — with a param of ‘up’ which would be either true or false. The action would create the vote record if needed, or would otherwise modify it.
3) As part of the creation process of the main record, you could always create the vote_record. That way, the voting operations would always be updates since the vote_record will always already exist.
Added
Re: comment of when is it generally “acceptable” to move away from a rest call?
Rest is a design philosophy. It solves a lot of problems but doesn’t fit all situations. I’d think that your original question would be ok but ultimately it is up to you and whomever reviews your architecture. Since it is possible to “bend” your app into a rest api for this function, some might tell you to do so–to thereby gain the benefit of not violating Restfulness.
Re: your example in your comment about friend relationships:
Since it makes sense to “create a friend relationship” it’d be better, other things being equal, to express the api as a rest “friendship object/create” call. It was exactly for your friending example that rest was created. — The old style alternative is that each api developer had to figure out a large set of procedure names.
Rest provides a more consistent, standard way of creating the names.
Note that a “change_vote” procedure would be best defined as part of the votes object: either votes/change_vote or something similar. I believe that there is a “Rails way” for urls for rest procedures that don’t fit the standard rest verbs.