RESTful, efficient way to query List.contains(element)?

Question

Given:

/images: list of all images
/images/{imageId}: specific image
/feed/{feedId}: potentially huge list of some images (not all of them)

How would you query if a particular feed contains a particular image without downloading the full list? Put another way, how would you check whether a resource state contains a component without downloading the entire state? The first thought that comes to mind is:

Alias /images/{imageId} to /feed/{feedId}/images/{imageId}

Clients would then issue HTTP GET against /feed/{feedId}/images/{id} to check for its existence. The downside I see with this approach is that it forces me to hard-code logic into the client for breaking down an image URI to its proprietary id, something that REST frowns upon. Ideally I should be using the opaque image URI. Another option is:

Issue HTTP GET against /feed/{feedId}?contains={imageURI} to check for existence

but that feels a lot closer to RPC than I'd like. Any ideas?

Answer 1

What's wrong with this?

HEAD /images/id

It's unclear what "feed" means, but assuming it contains resources, it'd be the same:

HEAD /feed/id

Answer 2

It's tricky to say without seeing some examples to provide context.

But you could just have clients call HEAD /feed/images/{imageURI} (assuming that you might need to encode the imageURI). The server would respond with the usual HEAD response, or with a 404 error if the resource doesn't exist. You'd need to code some logic on the server to understand the imageURI.

Then the client either uses the image meta info in the head, or gracefully handles the 404 error and does something else (depending on the application I guess)

Answer 3

How about setting up a ImageQuery resource:

# Create a new query from form data where you could constrain results for a given feed.
# May or may not redirect to /image_queries/query_id.
POST /image_queries/

# Optional - view query results containing URIs to query resources.
GET /image_queries/query_id

This video demonstrates the idea using Rails.

Answer 4

There's nothing "un-RESTful" about:

/feed/{feedId}?contains={imageURI}[,{imageURI}]

It returns the subset as specified. The resource, /feed/{feedid}, is a list resource containing a list of images. How is the resource returned with the contains query any different?

The URI is unique, and returns the appropriate state from the application. Can't say anything about the caching semantics of the request, but they're identical to whatever the caching semantics are of the original /feed/{feedid}, it simply a subset.

Finally, there's nothing that says that there even exists a /feed/{feedid}/image/{imageURL}. If you want to work with the sub-resources at that level, then fine, but you're not required to. The list coming back will likely just be a list of direct image URLS, so where's the link describing the /feed/{feedid}/image/{imageURL} relationship? You were going to embed that in the payload, correct?