Re[17]: REST API, практические вопросы
От: · Великобритания  
Дата: 19.05.16 13:45
Оценка:
Здравствуйте, Sharov, Вы писали:

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


S>Вводим состояние.

Говоришь шарадами.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Отредактировано 19.05.2016 13:46 · . Предыдущая версия .
Re: REST API, практические вопросы
От: bnk СССР http://unmanagedvisio.com/
Дата: 20.05.16 23:14
Оценка: +1
Здравствуйте, Artem Korneev, Вы писали:

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


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


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


IMHO, мотивация вполне разумная. Я бы не парился и делал через POST. У нас например все DELETE и PUT блокируются на роутерах, в результате все через POST.
Если упереться рогом и требовать соответствия канону, можно так ничего и не сделать.
Re[9]: REST API, практические вопросы
От: Adnin  
Дата: 24.11.16 16:38
Оценка:
Здравствуйте, Sharov, Вы писали:

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


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


Вы путаете утечку ресурсов(leak) с использованием ресурсов(usage).
Re[3]: REST API, практические вопросы
От: Pzz Россия https://github.com/alexpevzner
Дата: 24.11.16 16:45
Оценка:
Здравствуйте, Artem Korneev, Вы писали:

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


Это и есть POST, когда параметры передаются в бодю.
Re[2]: REST API, практические вопросы
От: Pzz Россия https://github.com/alexpevzner
Дата: 24.11.16 17:08
Оценка:
Здравствуйте, pestis, Вы писали:

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


Я не большой специалист по вебовскому программированию. А скажете, правильно ли я понимаю, что для реализации всего этого богатства потребуется где-то на стороне сервера создать запись в базе данных, которая будет связывать этот токен со стоящими за ним аргументами? Причем кто-то еще должен будет следить, чтобы уже не нужные/всеми забытые записи не накапливались.
Re: REST API, практические вопросы
От: Pzz Россия https://github.com/alexpevzner
Дата: 24.11.16 17:19
Оценка: +1
Здравствуйте, Artem Korneev, Вы писали:

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


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

Стоит ли идеологическая чистота всех этих лишних накладных расходов?
Re: REST API, практические вопросы
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 24.11.16 18:16
Оценка:
Здравствуйте, 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 не нашел. А было бы удобно
и солнце б утром не вставало, когда бы не было меня
Отредактировано 25.11.2016 9:00 Serginio1 . Предыдущая версия . Еще …
Отредактировано 25.11.2016 8:55 Serginio1 . Предыдущая версия .
Re[10]: REST API, практические вопросы
От: Sharov Россия  
Дата: 24.11.16 19:41
Оценка:
Здравствуйте, Adnin, Вы писали:

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


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


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


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


Я имел ввиду преднамеренную(ожидаемую) утечку ресурсов. А leak непреднамеренная -- утечка памяти и т.д.
Кодом людям нужно помогать!
Re: REST API, практические вопросы
От: Буравчик Россия  
Дата: 24.11.16 21:29
Оценка: 85 (4) +1
Здравствуйте, Artem Korneev, Вы писали:

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


Можно использовать запрос POST с заголовком
X-HTTP-Method-Override: GET
Best regards, Буравчик
Re[3]: REST API, практические вопросы
От: pestis  
Дата: 25.11.16 06:06
Оценка: 12 (1)
Здравствуйте, Pzz, Вы писали:


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

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

Неправильно понимаешь, все современные вебные фреймворки имеют временное хранилище для таких случаев и автоматически умеют следить за временем жизни записей. Правильный воркфлоу такой:
1. Получили реквест на поиск
2. Запустили в фоне поисковый запрос
3. Вернули токен не дожидаясь окончания поиска
4. Поисковый запрос отработал и сложил результаты во временное хранилище
5. Получили запрос по токену
6. Вернули результаты
Re[4]: REST API, практические вопросы
От: Pzz Россия https://github.com/alexpevzner
Дата: 25.11.16 07:25
Оценка:
Здравствуйте, pestis, Вы писали:

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

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

Интересно, что в этой конструкции перевешивает, выигрыш от распараллеливания поиска с сетевым общением между клиентом и сервером, или проигрыш от удваивания количества запросов и увеличения нагрузки на сервер?
Re[4]: REST API, практические вопросы
От: hrensgory Россия  
Дата: 25.11.16 07:40
Оценка:
25.11.2016 9:06, pestis пишет:

>Правильный воркфлоу такой:

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

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

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

--
WBR,
Serge.
Posted via RSDN NNTP Server 2.1 beta
Re[2]: REST API, практические вопросы
От: Max Mustermann  
Дата: 25.11.16 08:24
Оценка:
Здравствуйте, 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].
Re[5]: REST API, практические вопросы
От: pestis  
Дата: 25.11.16 09:40
Оценка:
Здравствуйте, Pzz, Вы писали:

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


Перевешивает удобство пользователя. Смотри, если в методе поиска параметры не пролазят в GET запрос, значит потенциально это долгий запрос потому что эти параметры не пролезут и в кэши. Значит разумнее показать пользователю спиннер вместо того чтобы тупить на GET запросе.
Re[6]: REST API, практические вопросы
От: Pzz Россия https://github.com/alexpevzner
Дата: 25.11.16 09:43
Оценка: +1
Здравствуйте, pestis, Вы писали:

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


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


Спиннер — это чего мы на экране рисуем, способ передачи N параметров — это вообще транспортный уровень, раскидывание одного запроса на два с обсчетом в фоне — это вопрос архитектуры. Это вообще разные вещи, они не связаны друг с другом. Никто не мешает послать долгий асинхронный GET, и одновременно рисовать хоть котиков на экране.
Re[7]: REST API, практические вопросы
От: pestis  
Дата: 25.11.16 10:12
Оценка:
Здравствуйте, Pzz, Вы писали:

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


Мешает архитектура браузера который не дает исполнять больше нескольких HTTP запросов одновременно.
Re[8]: REST API, практические вопросы
От: Pzz Россия https://github.com/alexpevzner
Дата: 25.11.16 10:17
Оценка:
Здравствуйте, pestis, Вы писали:

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


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


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

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

В третьих, если исполнение запроса занимает много времени на сервере, клиенту совершенно не легче от того, что он разобъет этот запрос на два.
Re[4]: REST API, практические вопросы
От: Sharov Россия  
Дата: 25.11.16 13:23
Оценка:
Здравствуйте, pestis, Вы писали:

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

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

Где про это можно попкорнее почитать?
Кодом людям нужно помогать!
Re[5]: REST API, практические вопросы
От: pestis  
Дата: 28.11.16 05:45
Оценка: 12 (1)
Здравствуйте, Sharov, Вы писали:

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


Ричардсон, RESTful Web API
Re[2]: REST API, практические вопросы
От: Mihas  
Дата: 28.11.16 06:14
Оценка:
Здравствуйте, bnk, Вы писали:

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