Каков правильный способ обработки запросов кэширования HTTP OData?

Question

Я хочу использовать OData и получить некоторые преимущества от кеширования HTTP. Я установил правило «у одного объекта есть один URI». Есть много способов, как выполнить запрос к одной сущности, позволяет сказать, что продукт с SKU = 123 (который является ПК):

/MyService.svc/Product(123) 

или

/MyService.svc/Product?$filter=sku eq 123 

или даже

/MyService.svc/Product(123)?$filter=sku eq 123 

наиболее неясным способом запроса этого продукта является:

/MyService.svc/Product?$filter=title eq 'Some handy product' 

(позволяет ожидать, что этот запрос возвращает только один объект - продукт 123)

Мой вопрос: , что является наиболее OData-полосная, как реагировать на такого рода запросов?

После некоторых исследований, мое последнее мнение:

• пусть продукт (123) работы как
• в случае $ фильтра = СК эк 123/ID эк 123 отвечает с HTTP 302 и расположением заголовка указывая на продукт (123).
• в случае продукта (123)? $ Filter = sku eq 123 для ответа 400 (Bad Request), потому что его глупо. Или, может быть, с перенаправлением 302 на продукт (123).

Но что делать с последним случаем?

Answer 1

товаров (123) -> Вы должны вернуть единое целое в вашей полезной нагрузке ответа

продукт (123) $ фильтра = ы э 123 -> Это на самом деле не имеет смысла - фильтр должен применять к коллекциям объектов, а Product (123) идентифицирует единый объект (всегда). Многие службы OData сегодня игнорируют это из-за поведения или ранних стеков серверов, но 400 приемлемо, поскольку опция запроса не применяется.

Продукт? $ Filter = sku eq 123 -> Продукт идентифицирует набор объектов, поэтому необходимо вернуть коллекцию объектов (канал АКА). Несмотря на то, что ваш конкретный запрос возникает, чтобы идентифицировать один объект, фид с одним объектом в нем является ТРЕБУЕМЫМ ответом.

Продукт? $ Filter = title eq 'Некоторые полезные продукты' -> Это то же самое, что и sku eq 123 с точки зрения ожидаемого ответа. Несмотря на то, что он может идентифицировать один ресурс, это не изменяет того факта, что набор объектов должен по-прежнему содержать фид в качестве ответа.

Вы сказали, что хотите сохранить правило, что у одного объекта есть один URL. В OData один URL-адрес идентифицирует объект, хотя несколько URL-адресов могут предоставить вам ту же информацию об этом. Поэтому я бы сказал, что с тобой все в порядке. Один URL-адрес, который идентифицирует ресурс, называется каноническим URL-адресом. Продукт (123) является каноническим URL. В, скажем, полезной нагрузке JSON, odata.id предоставит канонический URL-адрес объекта.

А как насчет этих других запросов, которые SEEM ссылаются на одну и ту же сущность? В действительных примерах фильтров (3-й и 4-й) ваш путь идентифицирует КОЛЛЕКЦИЮ, как я указал выше. Тот факт, что коллекция содержит только одну сущность, не имеет значения. Путь, который ИДЕНТИФИКАЦИЯ ресурса по-прежнему является продуктом (123).Другие URL-адреса могут предоставлять информацию об этом объекте без его идентификации. Поэтому я не думаю, что вы нарушили свое утверждение.

Чтобы ответить на часть 3xx вашего вопроса: вы всегда можете ответить на запрос с каким-то перенаправлением - это часть HTTP, а OData не изменит это. Тем не менее, для перенаправления на то, что не совпадает с исходным запросом, было бы неправильным поведением сервера. Например, Product (123)? $ Filter = any идентифицирует объекты Collection of Product. Перенести на продукт (123) было бы плохой идеей, на мой взгляд, поскольку она идентифицирует единую сущность. Ответ, который вы выписали, будет выглядеть по-другому! Я был бы удивлен, если бы какие-либо существующие клиенты OData могли справиться с этим, и я бы не ожидал, что новые обработают его.

Что это значит для HTTP-кеширования? Ну, откровенно говоря, по крайней мере, в приведенном сценарии, я не думаю, что вы должны делать что-то особенное.