¿Cómo diseñarías un sistema de votación RESTful?

Question

En mi búsqueda continua para tratar de concentrarme en lo RESTful-ness, he venido a otro lugar donde no estoy seguro de cómo proceder. Configuré un resumen de mi pensamiento en el que diseñaba un sistema de votación simple para un recurso, al igual que SO permite votar preguntas. Por lo tanto, decir que mi recurso es una imagen, y puedo conseguir una imagen mediante una identificación, así:

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

Y en este ejemplo, que los rendimientos decir, una representación JSON de una imagen, de este modo:

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

¿Cómo diseñaría una manera de "votar" en esa imagen? Me gustaría dos operaciones; voto arriba y voto abajo. El cliente no debe saber cuánto peso lleva cada uno, porque me gustaría que el premio para un voto positivo/negativo se decida a nivel de servidor para poder cambiarlo en cualquier momento que lo desee.

Mi primera idea era tener algo como esto:

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

a esa URL, uno puede publicar algo como lo siguiente:

{ 
"Vote":"UpVote" 
} 

Pero estoy cuidado con los que - para mí eso dice RPC disfrazado ¿Sería esa una pobre forma de diseñar esto? Si es así, ¿qué otros diseños podría probar?

Answer 1

Para ser reparador debe devolver algo como esto

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

En lo que se refiere RESTO no importa lo que el formato de los enlaces son. Mientras su cliente sepa que se supone que debe hacer POST al "UpVoteLink" o "DownVoteLink", no le importaría menos el formato de la URL.

Además, si decide en dos semanas que no le gustan las URL que eligió, puede cambiarlas y ¡a nadie le importará!

bien, está bien, si realmente quieres una sugerencia para un diseño url, ¿qué hay de

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 

Lo que es bueno de este diseño es que se puede votar en imágenes que no son ni siquiera en su sitio!

Answer 2

Al parecer tonto a mí para publicar una respuesta simple como que envuelto en JSON

¿Por qué no es algo tan simple como este, que podría hacerlo en una llamada AJAX para que sea súper agradable ..

Una petición GET formateadas como sigue

http://www.mysite.com/vote.php?image=123&vote=up 

o POST (este ejemplo utilizando jQuery)

$.post("http://www.mysite.com/vote.php", {image:"123", vote:"up"}); 

(Suponiendo PHP, pero se aplica lo que sea)

Answer 3

Si está trabajando con rieles, me gustaría ir a este encuentro URL:

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

y

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

1. Define las acciones "up_vote" y "down_vote" en tu controlador de Imágenes y haz que aumente o disminuya el valor de voto de tu objeto de modelo de imagen.

2. ajustar la siguiente ruta en config/routes.rb:

map.resources :images, :member => { :up_vote => :get, :down_vote => :get } 

... y ya está (más o menos ;-)).

Answer 4

Las API REST se supone que representan sustantivos, por lo que creo que tiene la primera parte correcta: una sola imagen se representa con una sola URL (por ejemplo, http://www.mysite.com/images/123123). No estoy seguro de hacer tachuelas en /up_vote y /down_vote is el camino a seguir.

http://www.mysite.com/images/123123 es el objeto y desea modificar eso, no alguna otra URL (a menos que estaban haciendo http://www.mysite.com/votes/images/123123). Creo que deberías simplemente POSTAR al http://www.mysite.com/images/123123. Esto hace que las solicitudes GET sean intrínsecamente no destructivas, ya que solo recupera la imagen, conserva un diseño RESTful y mantiene limpias sus URL.

Answer 5

En términos de recursos, una imagen es una cosa que tiene un URI (eso es lo que lo convierte en un recurso). Además de eso, tiene un montón de propiedades (tamaño, datos EXIF, etc.).

Cuando piense en los votos para una imagen, pregunte si los votos son un recurso en sí mismos.

Lo más probable es que al hacer un GET en/images/23/votes se devuelva un resumen o la lista de todos los votos que la interfaz de usuario usaría para mostrar junto a la imagen. Cuando quiera cambiar esos votos, el recurso que está cambiando son los votos.

Para estar tranquilo, el cliente solo necesita comprender el tipo de medio que ha diseñado, no los URI o el proceso a seguir para votar.

En su ejemplo, debe definir un nuevo formato utilizado en todas partes en su sitio. Reformular yoru ejemplo, un GET/images/23/votos regresarían (en XML, pero se puede reformular en 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> 

La idea detrás de este formato es que usted tiene una manera universal a definir la forma en la el cliente envía los datos al servidor y crea el documento. Todos los ejemplos anteriores que se han mostrado correctamente hacen que el URI dependa del servidor. Propongo que lo que envíe al servidor se defina en los formularios que envió el servidor.

Dedique más tiempo a definir cómo el cliente de yoru json va a entender cómo construir objetos json para el envío basado en un lenguaje de formulario general, y encontrará que una vez hecho esto, tiene un acoplamiento muy bajo entre servidor, y el servidor tiene la flexibilidad de cambiar todos los detalles sin romper sus clientes.