Фильтрация в GET в RESTful

Question

[arturich]

Всем привет! Меня давно мучает вопрос:

допустим у приложения REST api, допустим оно поддерживает запросы вроде этого:

GET /rest-api/models/?idModel=1,2,3,4,5,6,...

Допустим метод возвращает информацию о моделях товаров, идентификаторы которых указаны в запросе.
Все мы знаем, что получать инфу по каждой модели отдельно не прикольно, поэтому групповой запрос в самый раз.

Проблема
А что, если id-шников в get запросе слишком много, или у меня в приложении они десятизначные — в GET не так много может уместиться. Получается в угоду RESTful принципам я должен ухудшить производительность? Вроде звучит как бред — тот же POST запрос, имеющий в теле id-шники будет куда круче.

Что скажет общественность?

Comments

[arturich]

Решение в моем случае: не идти на поводу у REST, так как конкретно мне в моем проекте он мешает больше, чем помогает.

Всем большое спасибо!

Answer 1

[EugeneOZ]

Получается в угоду RESTful принципам я должен ухудшить производительность?

Да. Производительность никогда не была сильной стороной REST. Время, затраченное на открытие соединения, часто гораздо выше, чем время ответа. Для производительности используйте RPC.

тот же POST запрос, имеющий в теле id-шники будет куда круче

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

Comments

[Алексей Гусейнов]

А в RPC соединение открывать не надо?

[EugeneOZ]

Одно на все команды.

[arturich]

Да, пожалуй, на днях 3-4 вечера изучал rest принципы и видимо проглядел, где там описывается групповое создание ресурса, а может и нет этого в спецификации.

[arturich]

Получается зачем RESTful API, если сервис в любой момент может расшириться и GET просто не хватит при использовании фильтров. Получается, что есть вариант, при котором вам придется переписать API и вызовы. Это жесть. Не понимаю подоплеку всего этого REST.

[EugeneOZ]

Разбейте список на несколько вызовов, если не влезает, делов то.

[Алексей Гусейнов]

Одно на все команды.

Ну и в REST оно одно. У HTTP 1.1 есть специальный режим, когда после выполнения запроса соединение используется для последующих запросов.

Да, пожалуй, на днях 3-4 вечера изучал rest принципы и видимо проглядел, где там описывается групповое создание ресурса, а может и нет этого в спецификации.

У REST вообще нет спецификации. Можете определить PUT в коллекцию объектов коллекции объектов как замещение уже существующих объектов и создание новых. Так, как работает операция update у dict'а в Python. Это будет соответствовать семантике PUT и позволит массово создавать и модифицировать объекты.

[arturich]

Это так скажем спецификация/рекомендация ну или что-то типо того от мужика, который все это двигает.

Разбивать на несколько запросов не всегда круто, особенно когда id — какой-нибудь хеш и у вас вообще их штук 50 вмещается в url, а POST позволил бы более адекватные объемы получить.

[EugeneOZ]

соединение используется для последующих запросов

есть огромная разница между последовательными и параллельными запросами.

[arturich]

Ребята, вроде это не заслуга и не преимущество REST, это можно использовать в любой реализации API

[Алексей Гусейнов]

Это так скажем спецификация/рекомендация ну или что-то типо того от мужика, который все это двигает.

А я всегда думал, что это другой мужик стоит за REST: en.wikipedia.org/wiki/Roy_Fielding
Что это он в 2000 году написал докторскую диссертацию:
www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
Если хочется понять, что такое REST и что в нем ГЛАВНОЕ, надо читать её. Там объяснено почему надо делать так или иначе, какие цели достигаются какими приемами. А то, что по приведенной вами ссылке краткое изложение основных практических положений REST и некоторое количество отсебятины касающейся практической стороны, но не касающейся REST. В том числе REST не требует использования HTTP, человеко-понятных-URL, использования путиЮ а не аргументов для идентификации объектов, JSON, XML. И он целиком опирается на гиперссылки между ресурсами, а не " While services are still useful without them". А касательно «Create Fine-Grained Resources» в диссертации Филдинг наоборот пишет, что HTTP разрабатывался в первую очередь для пересылки большие документов.

Разбивать на несколько запросов не всегда круто, особенно когда id — какой-нибудь хеш и у вас вообще их штук 50 вмещается в url, а POST позволил бы более адекватные объемы получить.

Я понимаю. Но я бы рассматривал это как последний вариант, который стоит использовать, если не найдется другого более красивого решения.

есть огромная разница между последовательными и параллельными запросами.

Используйте SPDY, он будет через один сокет гнать несколько HTTP соединений. Кстати, откуда в RPC вы возьмете параллельные запросы через одно содениение? Или речь не о HTTP RPC?

[EugeneOZ]

Используйте SPDY

я как-то ближе к реальности.

речь не о HTTP RPC?

HTTP это всего лишь один из вариантов транспорта для RPC, и не всегда самый лучший.
Посмотрите на реализацию JSON RPC.

[EugeneOZ]

kibergus, спасибо за напоминание про keep-alive — обратил ещё раз на него своё внимание и смог получить улучшение производительности в клиенте :)

[Алексей Гусейнов]

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

Answer 2

[Алексей Гусейнов]

В POST запросе круче не будет т.к. не будет работеть кеширование.

Любопытнее другой вопрос, действительно ли обработка N запросов на получение объектов медленее, чем обработка 1 запроса на получение N объектов. При условии, что клиент посылает все запросы через одно HTTP соединение, а сервер использует persistent соединения с СУБД. Если объекты достаточно тяжелые, лишние накладные расходы могут оказаться малы. А теперь если учесть, что гранулярность кеширования увеличилась и клиент не будет запрашивать один и тот же объект дважды, может получиться так, что N запросов будут работать быстрее. А если клиент и сервер поддерживают SPDY и запросы пойдут не последовательно а параллельно, то ценой увеличения нагрузки на сервер можем получить уменьшение времени отклика. Сейчас низкое время отклика вроде бы ценится.

Comments

[arturich]

> В POST запросе круче не будет т.к. не будет работеть кеширование
Кеширование это бесспорно круто, но как вы его контролируете? Есть ресурсы, которые нельзя кешировать, да и просто, допустим список моделей может время от времени изменятся (как и всё), а вы будете отдавать старую версию. Именно такой вариант можно разрулить коде вашего приложения — оно и будет кеш сбрасывать, если меняет инфу в табличке. Вебсерверу вы кеш вроде как так просто не сбросите.

По второму абзацу — может, но не уверен, все же групповые операции, это групповые. Плюс в условиях общедоступного API наверняка не заставите клиентов использовать все это.

p.s. Яндекс не от хорошей жизни этот случай как POST сделал, думаю api.yandex.ru/market/partner/doc/dg/reference/post-models.xml

[EugeneOZ]

Именно такой вариант можно разрулить коде вашего приложения — оно и будет кеш сбрасывать

REST API не должно отдавать ответы из кэша, кэшировать должен клиент. REST API может только выдавать заголовки, содержащии рекомендации к кэшированию.

[arturich]

Полезная информация, спасибо. Пропустил видимо её до этого.

[Алексей Гусейнов]

REST API не должно отдавать ответы из кэша, кэшировать должен клиент.

Нет, кеширование доспускается на любом уровне, в том числе промежуточным proxy сервером, о существовании котороно не знает ни клиент, ни сервер. Это фишка, позволяющая снизить связность и уменьшить задержки. Чтобы кеширование правильно работало в стандарте HTTP описана семантика HTTP методов и заголовки управления кешированием.

REST API может только выдавать заголовки, содержащии рекомендации к кэшированию.

А еще клиент может выставлять заголовки типа If-Modified-Since, чтобы не непегружать канал, если данные не обновились.

[EugeneOZ]

Нет, кеширование доспускается на любом уровне

ага, если выкинуть букву S, STATELESS

[Алексей Гусейнов]

Наоборот, за счет отсутствие состояния общение между клиентом и сервером становится прозрачным и его семантика понятна любому промежуточному звену (layered system). Это и позволяет организовать кеширование. Также отсутсвие состояния позволяет создавать высоконадежные и высокопроизводительные системы.
Вот когда появляется состояние, возникает куча технических проблем и плясок с бубнами.

Answer 3

[Алексей Гусейнов]

Есть еще один интересный вопрос: зачем клиенту понадобилось запрашивать с сервера много моделей по ID? Что объединяет эти объекты? Это какая-то сущность, которая есть на клиенте, но о которой не известно серверу. Возможно стоит ввести эту сущность и проблема отпадёт.

Comments

[arturich]

Считайте, что клиент — это SAAS проект, и модели, это примерно как список городов, только примерно раз в 1-2 дня обновляющихся и по некоторым надо получить инфу. Номер модели содержится в товаре, но я уверен, что запрашивать такую инфу надо пачкой, а не /api/offer/777/model. Так как групповые операции с БД всегда быстрее (когда в разумных пределах выборка)

[Алексей Гусейнов]

Так сделайте тогда объект-коллекцию «модели обновленные после XXX». В каждом элементе возвращаемого списка не забудте прописать URL модели, чтобы их можно было положить куда следует. Если они обновляются раз в 1-2 дня, да еще не все сразу, то каждый такой список будет небольшим и ничего страшного в том, что там если лишние модели не будет. Зато будет предельно простой интерфейс.

[arturich]

Мы не знаем какие именно обновились, надо каждый день все выкачивать, а там их не одна тысяча.

[EugeneOZ]

если есть хоть какая-то возможность, лучше обеспечить это знание, делать фильтр на сервере и выдавать клиенту только обновлённые.

[Алексей Гусейнов]

Мы не знаем какие именно обновились, надо каждый день все выкачивать, а там их не одна тысяча.

Насколько я понимаю, обсуждается API сервера, а значит у вас есть контроль над сервером. Тогда и запоминать, когда изменились данные, не должно быть проблемой. В том числе можно сравнивать все поля новых данных с копией, имеющейся в базе и выявлять различия.

[arturich]

Я говорил о Яндексе. habrahabr.ru/qa/32929/#comment_159127

[Алексей Гусейнов]

Просто у маркета API ни разу не REST. И причин на это можерт быть много. Иногда это требования совместимости с используемыми версиями софта/браузерами/ОС мобильных телефонов. Например, пару лет назад отправить DELETE или PUT запрос иногда было просто невозможно. Иногда это инертность разработчиков, иногда особенности предметной области.
Если хотите пример REST API, то можете посмотреть на то, что предлагают Яндекс.Фотки. Оно сделано на основе atom.

Answer 4

[Михаил]

Попробуйте запихнуть их в хедеры

Comments

[arturich]

Некуда, да и REST предполагает фильтрацию в Url