How would you design a RESTful voting system? [closed]

Question

In my continuing quest to try and wrap my mind around RESTful-ness, I've come to another place where I'm not sure how to proceed. I set up a thought expiriment for myself where I'd design a simple voting system for a resource, much like how SO allows voting on questions. So, say my resource is an image, and I can get an image by an ID, like so:

http://www.mysite.com/images/123123

And in this example, that returns say, a JSON representation of an image, like so:

{
"URL":"http://www.mysite.com/images/123123.jpg",
"Rep":"100"
}

How would I design a way to "vote" on that image? I'd like two operations; up-vote and down-vote. The client shouldn't know how much weight each carries, because I'd like to have the award for an up-vote/down-vote be decided at the server level so I can change it anytime I like.

My first idea was to have something like this:

http://www.mysite.com/vote/images?image=123123

To that URL, one could POST something like the following:

{
"Vote":"UpVote"
}

But I'm wary of that - to me that says RPC in disguise. Would that be a poor way to design this? If so, what other designs could I try?

Answer 1

In terms of resources, an image is a thing that has a URI (that is what makes it a resource). Further than that, it has a bunch of properties (size, EXIF data, etc).

When you think of the votes for an image, question if the votes are a resource in themselves.

Chances are, doing a GET on /images/23/votes would return a summary or the list of all votes that the UI would use to display next to the image. Whenever you want to change those votes, the resource you're changing is the votes.

To be restful, the client needs to only understand the media type you've designed, not the URIs or the process to follow to vote.

In your example, you'd define a new format used everywhere on your site. To reformulate yoru example, a GET /images/23/votes would return (in xml but you can reformulate it in json):

<votes>
 <link href="/images/23" rel="subject" />
 <form action="/images/23/votes" mediatype="application/json">
   <submit name="Vote" value="Up">Vote up</submit>
   <submit name="Vote" value="Down">Vote down</submit>
 </form>
</votes>

The idea behind this format is that you have a universal way to define how the client sends the data to the server and build the document. All the previous examles that have been shown correctly make the URI dependent on the server. I propose that what you send to the server should be defined in forms that the server sent.

So spend more time defining how yoru json client is going to understand how to build json objects for submission based on a general form language, and you'll find that once this is done, you have very low coupling between cient and server, and the server has the flexibility to change all the specifics without breaking your clients.

Answer 2

To be restful you should return something like this

{
"URL":"http://www.mysite.com/images/123123.jpg",
"Rep":"100"
"UpVoteLink":"http://blah, blah, blah",
"DownVoteLink":"http://blah, blah, something else blah",
}

As far as REST is concerned it doesn't matter what the format of the links are. As long as your client knows that it is supposed to do POST to the "UpVoteLink" or "DownVoteLink" it couldn't care less what the format of the URL is.

Also, if you decide in two weeks that you don't like the URLs you picked, you can change them and no-one will care!

Ok, ok, if you really want a suggestion for an url design, how about

POST http://www.mysite.com/UpVotes?url=http://www.mysite.com/images/1234.jpg

POST http://www.mysite.com/DownVotes?url=http://www.mysite.com/images/1234.jpg

What is cool about this design is that you could vote on images that are not even on your site!