RESTful, эффективный способ запроса List.contains (element)?
Дано:
/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, чем мне бы хотелось. Любые идеи?
Ответы 4
Что в этом плохого?
HEAD /images/id
Неясно, что означает «канал», но если предположить, что он содержит ресурсы, это будет то же самое:
HEAD /feed/id
Сложно сказать, не увидев некоторых примеров, обеспечивающих контекст.
Но вы можете просто попросить клиентов вызвать HEAD /feed/images/{imageURI} (при условии, что вам может потребоваться кодировать imageURI). Сервер ответит обычным ответом HEAD или ошибкой 404, если ресурс не существует. Вам нужно будет запрограммировать некоторую логику на сервере, чтобы понять imageURI.
Затем клиент либо использует метаинформацию изображения в голове, либо изящно обрабатывает ошибку 404 и делает что-то еще (в зависимости от приложения, которое я думаю)
Я не думаю, что технически возможно нажать / feed / images / {imageURI}, потому что {imageURI} может содержать символы, которые необходимо заключать в кавычки. Предполагая, что я отбрасываю «http: //» и любые параметры запроса / матрицы из URI, вы будете правы. В идеале мне не нужно заранее ограничивать {imageURI} этим способом.
Я проголосовал за ваш ответ, потому что считаю, что, хотя у него есть проблемы, это, вероятно, лучший ответ на данный момент. Надеюсь, кто-нибудь найдет еще более чистое решение ...
Конечно, возможно, вы можете представить «что угодно» в URI. Если их нужно цитировать, значит, они должны быть процитированы. Но у вас должна быть общая логика, которая сделает это за вас, и вы все равно должны использовать ее сейчас. Это может быть некрасиво, но кого это волнует?
Как насчет настройки ресурса 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.
С другой стороны: это сработает. С другой стороны, это рискует превратиться в RESTful RPC. Если вы повторно используете один и тот же запрос, каждый раз меняя его настройки, он начинает звучать как настоящий ресурс. Сомнительно, так ли это, потому что потокобезопасный contains () требовал бы каждый раз создавать новый запрос.
Мне кажется, что как минимум каждому клиенту нужно будет создать свой собственный ресурс запроса, чтобы избежать проблем с потоками. Думаю, разумно синхронизировать доступ к списку внутри каждого клиента (по одному запросу на клиента), поэтому я еще немного подумаю. Хотел бы я сделать это без POST.
Нет ничего "не-RESTful" в:
/feed/{feedId}?contains = {imageURI}[,{imageURI}]
Он возвращает указанное подмножество. Ресурс / feed / {feedid} - это ресурс списка, содержащий список изображений. Чем отличается ресурс, возвращаемый запросом contains?
URI уникален и возвращает соответствующее состояние из приложения. Ничего не могу сказать о семантике кеширования запроса, но они идентичны любой семантике кеширования исходного / feed / {feedid}, это просто подмножество.
Наконец, ничего не говорится о существовании / feed / {feedid} / image / {imageURL}. Если вы хотите работать с подресурсами на этом уровне, тогда хорошо, но это не обязательно. Возвращаемый список, скорее всего, будет просто списком прямых URL-адресов изображений, так где же ссылка, описывающая отношение / feed / {feedid} / image / {imageURL}? Вы собирались встроить это в полезную нагрузку, верно?
Извините, я уточнил вопрос. / feed / {id} - ресурс, представляющий список изображений. Я не понимаю, как в этом случае поможет выдача HEAD / feed / id. В идеале я не хочу, чтобы клиенты могли разбивать / images / id на «id» (я бы предпочел связывать ресурсы, чем жестко кодировать логику).