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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ребята, вроде это не заслуга и не преимущество 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?

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

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

речь не о HTTP RPC?

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

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

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