Здравствуйте, alex_public, Вы писали:
_>Что и? В gPRC это возможно в рамках одного соединения, а в REST нет.
Возможно, хотя и с натяжкой.
_>Так встроено или надо допиливать сервер? 
Встроено в протокол. Реализация в сервере — дело добровольное.
_>Ты вот это сейчас серьёзно? ) Ты считаешь, что при запросе коллекции данных никому не придёт в голову указывать в запросе её срез и все будут возвращать только коллекцию целиком? )))
Конечно. Именно так. Давайте посмотрим на ваш "реальный пример" и убедимся, что, к примеру, в
https://tinkoff.github.io/investAPI/marketdata/#getlastpricesrequest не предусмотрено никакого способа запросить "
изменения цен с прошлого запроса".
Только коллекция целиком. И так всё и везде.
_>Ой, т.е. оказывается уже целая большая область обнаружилась, где REST сливает RPC?
А кто же у нас вот только что писал:
_>_> Прямо на этом сайте уже поднимались примеры "сложных задач", где применение RPC "очевидно" эффективнее. Во всех случаях, АФАИР, RPC проиграл. В рамках CRUD можно представить всё, что угодно. Более того — как раз такое представление и является единственно возможным способом строить распределённые приложения.
_>И вот уже "неожиданно" оказывается что не "во всех случаях"? )))
Ну так это же как раз несложная задача.
_>А если дальше пойдём разбираться, то вообще окажется что всё наоборот... )))
Не, если мы пойдём дальше разбираться, то как раз и окажется, что RPC уместен там, где не нужна надёжность.
_>Да, кстати, у ребят в указанном примере ещё год назад был REST интерфейс (OpenAPI и всё такое)... )))
Во-первых, почему "был"? Вот он и сейчас есть:
https://tinkoff.github.io/invest-openapi/rest/
Во-вторых, он никакой не REST. Это легко понять, посмотрев на список глаголов. У них все операции сделаны через POST — это как раз означает, что архитекторы тинькова — недоучки, и про REST не поняли ничего.
Это подтверждает мою гипотезу — на gRPC переходит не вся индустрия, а те, кто не осилил REST.
_>Нет, как раз требуется гарантированное извещение. И более того, условия ещё более жёсткие — оно требуется в чёткие интервалы времени (чуть позже и эта информация уже бесполезна). Однако сама эта задача априори требует нормальной работоспособности обеих сторон (иначе она просто не может быть решена). Так что вариант с корректной обработкой ситуации умершего клиента смешно даже рассматривать — это априори форс-мажор и потенциальная потеря денег.
Совершенно верно. Поэтому опытные HFT-пользователи размещают свои сервера в том же датацентре, что и биржа, не так ли
Но большинству простых смертных приложений такой роскоши, как сеть с надёжностью в шесть девяток, никто не даст. Поэтому делать вид, что решение, уместное для биржевых спекулянтов, подойдёт и "списку дел на сегодня" — как-то странно.
_>Да я смотрю ты и в этой области специалист.
Не надо быть специалистом, чтобы понять, как это будет работать. Во времена моей юности мышки были "продвинутым оборудованием", и часть народу на полном серьёзе утверждала, что в кваку можно играть и с клавиатурой.
Сетевой режим расставил всё по своим местам — мышевозы вытеснили клавишников.
Впрочем, мы же рассуждаем о воображаемой задаче. Вообразить-то можно всё что угодно — и пользователя, которому безразлично, в какую сторону смотреть. И оборудование, где на веб-камеру денег хватило, а на енкодер (или хотя бы оптопары для детектирования нулевого положения) — нет.
Я вот могу вам поверх вашей воображаемой задачи предложить другую, на которой ваше "очевидное" решение тут же сольётся: я хочу написать робота, который каждый час заходит в этот API, делает снимки с шагом в 15 градусов, и склеивает из них панораму. При этом связь, как обычно, ненадёжная, а каждая панорама должна быть корректной и выровненной по углу — я потом склею из неё time-lapse.
Если посмотреть с точки зрения архитектуры, то у вашей задачи и HFT есть одна общая черта: мы пренебрегаем ненадёжностью сети. В одном случае — потому, что мы готовы переплачивать за надёжность сети. В другом — потому что нам наплевать на результат. Ну, как eventual-to-never consistency: даже если у нас какой-то из визитов на страницу и не запишется в лог — ничего страшного.
_>Оу, видеопоток через REST... Это прямо максимально интересно становится.
А что вас удивляет? Сейчас так делают более-менее все. Вот, пару недель назад жена участвовала в конференции удалённо. Аудиовидеостриминг в реальном времени.
Благодаря тому, что это было сделано через REST, мы смогли записать полное видео — причём на второй день, записали и первый и второй дни.
Потому что вот так вот устроен стриминг — это не fire-and-forget протокол вроде UDP или RTP, а честный HTTP, причём именно в стиле REST. То есть там лежит некоторый ресурс, который мы можем "читать", а кто-то одновременно дописывает новые данные в хвост этого ресурса.
_>Эээ что? ) Весь смысл всего это в том, чтобы человек пейзажики смотрел...
Это вам сейчас так кажется. А потом выяснится, что человеку интересно, на север он смотрит, или на юг. И что его раздражает невозможность прицелиться в нужную сторону из-за лагающей обратной связи и теряющихся prev/next.
Даже формы опросников, сделанные в RPC стиле, раздражают до неимоверности (это те, где нельзя сделать back в браузере, а надо непременно жать кнопку "Назад").
_>Какого ещё архитектурного решения? У тебя есть физическая железка с заданными параметрами (условно двумя кнопками влево/вправо и кнопкой включения камеры, возвращающей поток кадров) и надо приделать к ней удалённый доступ.
_>Архитектуру можешь плодить какую хочешь. Но ты уже показал, что в рамках REST подхода ты можешь только слиться с невнятными оправданиями.
Почему же? я прикручу к этой железке датчик нуля, сделаю процедуру инициализации, и выставлю REST-протокол по управлению положением.
_>Это просто инструмент переходного периода. Когда хочется перейти на быстрые современные решения, но при этом надо поддерживать ещё и клиентов с устаревшими подходами...
Посмотрим, посмотрим.
