Здравствуйте, Sharov, Вы писали:

S>·>Ничего не понял. не stateless, а "stateless" что значит?

S>Вводим состояние.
Говоришь шарадами.

Здравствуйте, Artem Korneev, Вы писали:

AK>Далее.. позвал я ихнего техлида и он мне пояснил причину такого кода — в кач-ве параметра к запросу передаётся массив идентификаторов. Каждый идентификатор — около 30 символов. Если передавать их как параметры GET-запроса, то легко массив из 60 идентификаторов займёт уже пару килобайт и они не уверены, не превысит ли это лимитов длины HTTP-запроса.

AK>Вот второй, более важный вопрос — как такие вещи делаются по-человечески? Вот если нужно поддерживать GET-запросы, в которых длина аргументов тянет на пяток килобайт, как быть? Требовать разбивать запросы? Или плюнуть и запрашивать данные через POST-запрос, передавая параметры в теле запроса? Или настраивать Web-сервер, чтоб увеличить максимальную длину запроса?

AK>Посоветуйте. Кто-нибудь наверняка ведь сталкивался с ситуацией, когда для запроса данных нужно передать несколько десятков параметров. Может какие-то примеры есть среди общеизвестных REST-сервисов?

IMHO, мотивация вполне разумная. Я бы не парился и делал через POST. У нас например все DELETE и PUT блокируются на роутерах, в результате все через POST.
Если упереться рогом и требовать соответствия канону, можно так ничего и не сделать.

Здравствуйте, Sharov, Вы писали:

S>·>Почему _любое_ post — утечка ресурсов?

S>Блин, по определению. Реальность такова, что чтобы создать что-то необходимо использовать ресурсы (утечка ресурсов на создание). Если мы конечно же говорим о post как о создании ресурсов, а не о get с телом

Вы путаете утечку ресурсов(leak) с использованием ресурсов(usage).

Здравствуйте, Artem Korneev, Вы писали:

AK>Зачем такие сложности? Поддержка передачи параметров в "body" вполне решила бы проблему с длиной URL.

Это и есть POST, когда параметры передаются в бодю.

Здравствуйте, pestis, Вы писали:

P>По человечески это делается через POST метод %create_operation%, который принимает аргументы операции и возвращает токен. Затем по этому токену можно получить результат. Достоинства: идеологически верно, гарантированно не вызывает проблем с HTTP миддлварью, позволяет безболезненно прикрутить CQRS в реализации.

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

Здравствуйте, Artem Korneev, Вы писали:

AK>Вот второй, более важный вопрос — как такие вещи делаются по-человечески? Вот если нужно поддерживать GET-запросы, в которых длина аргументов тянет на пяток килобайт, как быть? Требовать разбивать запросы? Или плюнуть и запрашивать данные через POST-запрос, передавая параметры в теле запроса? Или настраивать Web-сервер, чтоб увеличить максимальную длину запроса?

Я бы не парился, и сделал POST. Разбиение запросов — это всегда некоторый overhead. Временное хранение пачки аргументов на сервере с токеном для ссылки на них — это БОЛЬШОЙ overhead, плюс изрядные архитектурные сложности.

Стоит ли идеологическая чистота всех этих лишних накладных расходов?

Здравствуйте, Artem Korneev, Вы писали:

Не в тему. Но меня заинтересовал Refit: The automatic type-safe REST library for .NET Core, Xamarin and .NET

Refit: The automatic type-safe REST library for Xamarin and .NET 2
Смысл в том, что мы можем для клиента описать интерфейс

public interface IGitHubApi
{
    [Get("/users/{user}")]
    Task<User> GetUser(string user);
}

The RestService class generates an implementation of IGitHubApi that uses HttpClient to make its calls:

var gitHubApi = RestService.For<IGitHubApi>("https://api.github.com");

var octocat = await gitHubApi.GetUser("octocat");

Но вот аналог для Asp.Net не нашел. А было бы удобно

Здравствуйте, Adnin, Вы писали:

A>Здравствуйте, Sharov, Вы писали:

S>>·>Почему _любое_ post — утечка ресурсов?

S>>Блин, по определению. Реальность такова, что чтобы создать что-то необходимо использовать ресурсы (утечка ресурсов на создание). Если мы конечно же говорим о post как о создании ресурсов, а не о get с телом

A>Вы путаете утечку ресурсов(leak) с использованием ресурсов(usage).

Я имел ввиду преднамеренную(ожидаемую) утечку ресурсов. А leak непреднамеренная -- утечка памяти и т.д.

Здравствуйте, Artem Korneev, Вы писали:

AK>Вот второй, более важный вопрос — как такие вещи делаются по-человечески? Вот если нужно поддерживать GET-запросы, в которых длина аргументов тянет на пяток килобайт, как быть? Требовать разбивать запросы? Или плюнуть и запрашивать данные через POST-запрос, передавая параметры в теле запроса? Или настраивать Web-сервер, чтоб увеличить максимальную длину запроса?

Можно использовать запрос POST с заголовком

X-HTTP-Method-Override: GET

Здравствуйте, Pzz, Вы писали:


Pzz>Я не большой специалист по вебовскому программированию. А скажете, правильно ли я понимаю, что для реализации всего этого богатства потребуется где-то на стороне сервера создать запись в базе данных, которая
будет связывать этот токен со стоящими за ним аргументами? Причем кто-то еще должен будет следить, чтобы уже не нужные/всеми забытые записи не накапливались.

Неправильно понимаешь, все современные вебные фреймворки имеют временное хранилище для таких случаев и автоматически умеют следить за временем жизни записей. Правильный воркфлоу такой:
1. Получили реквест на поиск
2. Запустили в фоне поисковый запрос
3. Вернули токен не дожидаясь окончания поиска
4. Поисковый запрос отработал и сложил результаты во временное хранилище
5. Получили запрос по токену
6. Вернули результаты

Здравствуйте, pestis, Вы писали:

P>Неправильно понимаешь, все современные вебные фреймворки имеют временное хранилище для таких случаев и автоматически умеют следить за временем жизни записей. Правильный воркфлоу такой:
P>1. Получили реквест на поиск
P>2. Запустили в фоне поисковый запрос
P>3. Вернули токен не дожидаясь окончания поиска
P>4. Поисковый запрос отработал и сложил результаты во временное хранилище
P>5. Получили запрос по токену
P>6. Вернули результаты

Интересно, что в этой конструкции перевешивает, выигрыш от распараллеливания поиска с сетевым общением между клиентом и сервером, или проигрыш от удваивания количества запросов и увеличения нагрузки на сервер?

25.11.2016 9:06, pestis пишет:

>Правильный воркфлоу такой:
> 1. Получили реквест на поиск
> 2. Запустили в фоне поисковый запрос
> 3. Вернули токен не дожидаясь окончания поиска
> 4. Поисковый запрос отработал и сложил результаты во временное хранилище
> 5. Получили запрос по токену
> 6. Вернули результаты

Такой воркфлоу представляется правильным только для очень длительных
запросов или генерации репортов (в этом случае их обычно складывают не
во временное а в более-менее постоянное хранилище).

В остальных случаях от п. 2-5 будет одно зло. Либо надо постоянно
опрашивать сервер, что или будет его нагружать, или (если период опроса
достаточно велик) приведет к тому, что рез-т уже готов, а пользователь
его всё никак не получает. Либо держать открытый вебсокет.

--
WBR,
Serge.

Здравствуйте, Vladek, Вы писали:

V> <httpRuntime targetFramework="4.5.1" maxUrlLength="10999" maxQueryStringLength="2097151" />

Лимит длины HTTP-запроса — он не только у сервера, но и у клиента. Например у IE это ~2K символов.

V>Передавал параметры в сервис в закодированном виде, по максимум убрав лишнюю информацию (там много чего можно сократить и выбросить). Аргумент у метода сервиса был простой строкой, которая парсилась и превращалась обратно в массив. Что-то вроде "<количество id>_<id1>_<id2>" и это здорово сокращало длину URL.

А тут вы не только не "решили проблему", но на ровном месте добавили себе гарантированныйе грабли для id вида [this_is_my_custom_id].

Здравствуйте, Pzz, Вы писали:

Pzz>Интересно, что в этой конструкции перевешивает, выигрыш от распараллеливания поиска с сетевым общением между клиентом и сервером, или проигрыш от удваивания количества запросов и увеличения нагрузки на сервер?

Перевешивает удобство пользователя. Смотри, если в методе поиска параметры не пролазят в GET запрос, значит потенциально это долгий запрос потому что эти параметры не пролезут и в кэши. Значит разумнее показать пользователю спиннер вместо того чтобы тупить на GET запросе.

Здравствуйте, pestis, Вы писали:

Pzz>>Интересно, что в этой конструкции перевешивает, выигрыш от распараллеливания поиска с сетевым общением между клиентом и сервером, или проигрыш от удваивания количества запросов и увеличения нагрузки на сервер?

P>Перевешивает удобство пользователя. Смотри, если в методе поиска параметры не пролазят в GET запрос, значит потенциально это долгий запрос потому что эти параметры не пролезут и в кэши. Значит разумнее показать пользователю спиннер вместо того чтобы тупить на GET запросе.

Спиннер — это чего мы на экране рисуем, способ передачи N параметров — это вообще транспортный уровень, раскидывание одного запроса на два с обсчетом в фоне — это вопрос архитектуры. Это вообще разные вещи, они не связаны друг с другом. Никто не мешает послать долгий асинхронный GET, и одновременно рисовать хоть котиков на экране.

Здравствуйте, Pzz, Вы писали:

Pzz>Спиннер — это чего мы на экране рисуем, способ передачи N параметров — это вообще транспортный уровень, раскидывание одного запроса на два с обсчетом в фоне — это вопрос архитектуры. Это вообще разные вещи, они не связаны друг с другом. Никто не мешает послать долгий асинхронный GET, и одновременно рисовать хоть котиков на экране.

Мешает архитектура браузера который не дает исполнять больше нескольких HTTP запросов одновременно.

Здравствуйте, pestis, Вы писали:

Pzz>>Спиннер — это чего мы на экране рисуем, способ передачи N параметров — это вообще транспортный уровень, раскидывание одного запроса на два с обсчетом в фоне — это вопрос архитектуры. Это вообще разные вещи, они не связаны друг с другом. Никто не мешает послать долгий асинхронный GET, и одновременно рисовать хоть котиков на экране.

P>Мешает архитектура браузера который не дает исполнять больше нескольких HTTP запросов одновременно.

Во-первых, это не правда. Несколько XmlHttpRequest могут исполняться параллельно.

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

В третьих, если исполнение запроса занимает много времени на сервере, клиенту совершенно не легче от того, что он разобъет этот запрос на два.

Здравствуйте, pestis, Вы писали:

P>Неправильно понимаешь, все современные вебные фреймворки имеют временное хранилище для таких случаев и автоматически умеют следить за временем жизни записей. Правильный воркфлоу такой:
P>1. Получили реквест на поиск
P>2. Запустили в фоне поисковый запрос
P>3. Вернули токен не дожидаясь окончания поиска
P>4. Поисковый запрос отработал и сложил результаты во временное хранилище
P>5. Получили запрос по токену
P>6. Вернули результаты

Где про это можно попкорнее почитать?

Здравствуйте, Sharov, Вы писали:

S>Где про это можно попкорнее почитать?

Ричардсон, RESTful Web API

Здравствуйте, bnk, Вы писали:

bnk У нас например все DELETE и PUT блокируются на роутерах,
Поясни, плиз.
Так работают роутеры, локализованные для вашей страны? Или я что-то не так понял?