RESTful, эффективный способ запроса List.contains (элемент)?

Question

Дано:

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

Как бы вы запросили, если конкретный канал содержит определенное изображение, не загружая полный список? Другими словами, как бы вы проверили, содержит ли состояние ресурса компонент без загрузки всего состояния? Первая мысль, которая приходит в голову:

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

Клиенты тогда будут выдавать HTTP GET против /feed/{feedId}/images/{id}, чтобы проверить его существование. Недостаток, который я вижу в этом подходе, заключается в том, что он заставляет меня жестко программировать логику в клиенте для разбиения URI образа на его собственный идентификатор, что вызывает недовольство REST. В идеале я должен использовать URI непрозрачного изображения. Другой вариант:

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

но это гораздо ближе к RPC, чем мне бы хотелось. Есть идеи?

Answer 1

Сложно сказать, не увидев несколько примеров для предоставления контекста.

Но вы могли бы просто заставить клиентов звонить HEAD /feed/images/{imageURI} (при условии, что вам может понадобиться кодировать imageURI). Сервер ответил бы обычным ответом HEAD или с ошибкой 404, если ресурс не существует. Чтобы понять imageURI, вам нужно написать код на сервере.

Затем клиент либо использует метаинформацию изображения в голове, либо изящно обрабатывает ошибку 404 и делает что-то еще (в зависимости от предполагаемого приложения)

Answer 2

Что с этим не так?

HEAD /images/id

Непонятно, что означает «подача», но при условии, что она содержит ресурсы, она будет такой же:

HEAD /feed/id

Answer 3

В этом нет ничего "не-RESTful":

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

Возвращает подмножество, как указано. Ресурс / feed / {feedid} представляет собой список ресурсов, содержащий список изображений. Чем отличается ресурс, возвращаемый с запросом содержимого?

URI является уникальным и возвращает соответствующее состояние из приложения. Ничего не могу сказать о семантике кэширования запроса, но они идентичны семантике кэширования оригинальной / feed / {feedid}, это просто подмножество.

Наконец, ничто не говорит о том, что существует даже / feed / {feedid} / image / {imageURL}. Если вы хотите работать с подресурсами на этом уровне, тогда все в порядке, но это не обязательно. Возвращающийся список, скорее всего, будет просто списком прямых URL-адресов изображений, так где же ссылка, описывающая отношение / feed / {feedid} / image / {imageURL}? Вы собирались вставить это в полезную нагрузку, правильно?

Answer 4

Как насчет настройки ресурса ImageQuery:

# 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

Это видео демонстрирует идею использования Rails.