Question

My design exposes two kinds of resources:

  1. Images
  2. Tags

I would like clients to be able to request random images by their tag(s). For example: Give me random images that are tagged with "New York" and "Winter". What would a RESTful design look like in this case?

Was it helpful?

Solution

To sum up all the discussion in the comments, and not to change my initial proposal, this is what I'd come up finally:

You want to access images via tags; each tag relates to a set of images. As a given tag may be used a lot more than another (say, New York photos used a lot more than Chicago's), you should use a RESTful configuration that allows caching, so you can cache New York photos. IMHO, the solution would be:

  • Each image has a fixed URI:

    http://www.example.com/images/12345
    
  • Each tag has also a URI:

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

    This URI acts as a random dispatcher of images on the set; it returns a 303 See Other response, redirecting to a random image of the set. By definition, this URI must not be cached, and the fixed one should, and the browser shouldn't understand that the redirection to the second resource is permanent, so it's optimal.

  • You could even access the whole set via:

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

    This access would result in a 300 Multiple Choices response; it returns the whole set (as URIs, not as images!) to the browser, and the browser decides what to do with it.

  • You can also use intersection of various tags:

    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.
    

So you have a fixed URI for each image, a fixed URI for each tag and its related set of photos, and a fixed URI for a random dispatcher that each tag has. You haven't need to use any GET parameters as other potential solutions, so this is as RESTful as you can get.

OTHER TIPS

I've struggled myself with this issue. What we ended up implementing was an HttpResponseRedirect from, eg:

http://www.example.com/randomNewYorkImage

to a random New York image:

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

The first resource can be conceived as a random New York images dispatcher. This solution will load more the server, as it will be requested two resources, but it is as RESTful as you can get.

Edited: Plus, if you are caching, each image will be in the cache, and your server goes from sending an image to sending only the redirect, as the cache will intercept the second request, and thus alleviating your server load.

Multi-dimensional resource identification is challenging.

Your resource is an image, so that's your URI. Further, a specific image has a specific URI which never changes.

Your "by tag" is a non-identifying attribute of the resource. For this, a query string can belp.

Here's my first thought.

  • http://www.example.com/MyStuff/image/id/ -- specific image by id
  • http://www.example.com/MyStuff/image/?tag=tagname -- random image with a given tag, implicitly, count=1.
  • http://www.example.com/MyStuff/image/?tag=tagname&count=all -- all images with a given tag in a random order (count=1 is the default, which would give you an arbitrary image)

I'd do something like http://foo.com/image/tagged/sometag/random and stop losing sleep over it.

I agree with Triptych on this one. In a way adding random to the end of the URI makes it feel like an operation, but if it is scoped to a tag then you're really just refining the context.

In his example of:

/image/tagged/sometag/random

images resource -> tagging scope (all images with tags) -> specific tag (all images with tag X) -> random (a resource from the scoped list of images with tag X)

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top