¿Cómo devolver artículos aleatorios RESTfully?

Question

Mi diseño expone dos tipos de recursos:

1. Imágenes
2. Etiquetas

Me gustaría que los clientes puedan solicitar imágenes aleatorias por su (s) etiqueta (s). Por ejemplo: dame imágenes al azar que estén etiquetadas con " Nueva York " y " Invierno " ;. ¿Cómo sería un diseño RESTful en este caso?

Answer 1

Para resumir toda la discusión en los comentarios, y no para cambiar mi propuesta inicial, esto es lo que finalmente surgió:

Quieres acceder a las imágenes a través de etiquetas; Cada etiqueta se relaciona con un conjunto de imágenes. Como una etiqueta dada se puede usar mucho más que otra (por ejemplo, las fotos de Nueva York se usan mucho más que las de Chicago), debe usar una configuración REST que permita el almacenamiento en caché, para que pueda almacenar en caché las fotos de Nueva York. En mi humilde opinión, la solución sería:

• Cada imagen tiene un URI fijo:

  http://www.example.com/images/12345
  

• Cada etiqueta también tiene un URI:

  http://www.example.com/tags/New_York/random
  

  Este URI actúa como un despachador aleatorio de imágenes en el conjunto; devuelve una 303 See Other respuesta, redirigiendo a Una imagen aleatoria del conjunto. Por definición , este URI no debe almacenarse en caché. y el fijo debería, y el navegador no debería entender que la redirección al segundo recurso es permanente, por lo que es óptima.

• Incluso podría acceder a todo el conjunto a través de:

  http://www.example.com/tags/New_York
  

  Este acceso resultaría en un 300 opciones múltiples respuesta; devuelve todo el conjunto (como URI, no como imágenes) al navegador, y el navegador decide qué hacer con él.

• También puede usar la intersección de varias etiquetas:

  http://www.example.com/tags/New_York/Autumn/Manhattan/random
  http://www.example.com/tags/Autumn/Manhattan/New_York/random (equivalent to the previous one)
  http://www.example.com/tags/New_York/girls/Summer/random
  etc.
  

Por lo tanto, tiene un URI fijo para cada imagen, un URI fijo para cada etiqueta y su conjunto de fotos relacionadas, y un URI fijo para un distribuidor aleatorio que tiene cada etiqueta. No necesita utilizar ningún parámetro GET como otras soluciones potenciales, por lo que es lo más RESERVABLE que puede obtener.

Answer 2

He luchado con este problema. Lo que terminamos implementando fue un HttpResponseRedirect de, por ejemplo:

http://www.example.com/randomNewYorkImage

a una imagen aleatoria de Nueva York:

http://www.example.com/images/New_York/1234 .

El primer recurso se puede concebir como un distribuidor aleatorio de imágenes de Nueva York. Esta solución cargará más el servidor, ya que se le solicitarán dos recursos, pero es lo más RESERVABLE que pueda obtener.

Editado: Además, si está almacenando en caché, cada imagen estará en el caché, y su servidor pasará de enviar una imagen a enviar solo el redireccionamiento, ya que el caché interceptará la segunda solicitud y, por lo tanto, aliviará la carga de su servidor.

Answer 3

La identificación de recursos multidimensionales es un desafío.

Tu recurso es una imagen, así que esa es tu URI. Además, una imagen específica tiene un URI específico que nunca cambia.

Tu " por etiqueta " Es un atributo no identificable del recurso. Para esto, una cadena de consulta puede ser belp.

Aquí está mi primer pensamiento.

• http://www.example.com/MyStuff/image/id / - imagen específica por ID
• http://www.example.com/MyStuff/image/?tag= tagname : imagen aleatoria con una etiqueta determinada, implícitamente, cuenta = 1 .
• http://www.example.com/MyStuff/image/?tag=tagname & amp; count = all - all imágenes con una etiqueta dada en un orden aleatorio ( count = 1 es el valor predeterminado, lo que le daría una imagen arbitraria)

Answer 4

Haría algo como http://foo.com/image/tagged/sometag/random y dejaría de perder el sueño por eso.

Answer 5

Estoy de acuerdo con Tríptico en este caso. En cierto modo, la adición aleatoria al final del URI lo hace sentir como una operación, pero si está dentro del alcance de una etiqueta, en realidad solo estás refinando el contexto.

En su ejemplo de:

/ image / tagged / sometag / random

recurso de imágenes - > ámbito de etiquetado (todas las imágenes con etiquetas) - > etiqueta específica (todas las imágenes con etiqueta X) - > aleatorio (un recurso de la lista de imágenes con la etiqueta X con ámbito)