Re[9]: REST: прохой\хороший интерфейс
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.02.20 14:02
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Мне кажется, что ты пытаешься навязать RPC психологию HTTP, отсюда все проблемы , в частности, желание получить 304

Вот ровно всё — мимо.
1. Во-первых, проблемы не у меня, а у RPC. Это ущербная концепция, плохо применимая в сетевых реалиях.
2. Во-вторых, никакой "психологии" тут нет. Есть банальный прагматизм, выработанный многолетней практикой.

PD>304 Not Modified — сервер возвращает такой код, если клиент запросил документ методом GET, использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента.

Я в курсе, что такое Not Modified.
PD>Да, для HTTP это имеет смысл.
Конкретный код — да, имеет смысл только в рамках HTTP.
А сама концепция кэширования и delta-encoding выходит далеко за рамки HTTP.
PD>Я не буду, конечно, утверждать, что клиент РБД связывается с ней по именно по RPC. Там внизу скорее всего иначе. Но суть от этого не меняется.
PD>Запросил ты что-то с помощью SELECT и что ? Кто там не изменился и что должно возвращаться ? Нет такого понятия — не изменился. Просил — получи, а потом сам и разбирайся, что там изменилось, а что нет.
Ну, так это-то и плохо. Качаем терабайт данных для того, чтобы заменить одну строчку. Павел, ты уверен, что это — лучше, чем HTTP?
PD>Да еще учти, что пока разбираешься, там что-то могло измениться. Хочешь знать, когда изменялось — предусмотри в таблице timestamp.
Если тебе интересно, как сделать change tracking в RDBMS — обращайся. Я участвую в топиках на эту тему в соответствующем форуме в среднем ежегодно

PD>А 304... Ну что 304 ? Придуман во времена, когда ресурсы были в основном статическими, а If-Modified-Since реализовать было предельно просто : взять время последней модификации файла, и все дела.

(facepalm).
PD>А потом начали HTTP, который вовсе не был предназначен изначально для интерфейса со сложным серверным кодом, применять именно для этой цели. Понятно, что без проблем не обошлось.
И опять ровно всё — мимо.
Сначала для интерфейса со "сложным серверным кодом" начали применять RPC. Потом — RMI. Применение HTTP для этого возникло существенно позже. И, естественно, сначала усилия были вложены в противоположную сторону — люди взяли из HTTP ровно один глагол (самый бесполезный) и завернули RPC/RMI в XML over HTTP.
Получился проклятый SOAP.
И только через семь-восемь лет после публикации диссертации Филдинга передовики начали понимать, как правильно делать современные API в интернете. Чтобы они работали быстро, надёжно, и масштабируемо.
RPC тут оказался мимо тазика — во всех его инкарнациях.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[10]: REST: прохой\хороший интерфейс
От: Pavel Dvorkin Россия  
Дата: 12.02.20 15:31
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>Вот ровно всё — мимо.


Думаю, что все же не все

S>1. Во-первых, проблемы не у меня, а у RPC. Это ущербная концепция, плохо применимая в сетевых реалиях.


Ну это обсуждать не стоит. Она есть, она работает.

S>2. Во-вторых, никакой "психологии" тут нет. Есть банальный прагматизм, выработанный многолетней практикой.


На основании существующих рецептов и идей. Которые определяются в значительной мере этой практикой. Попробуй от нее отрешиться и подумай — если бы тебе дали возможность спроектировать протокол заново, ты бы точно сделал HTTP ? Сейчас, зная все, что есть, а не 20 веке.

S>А сама концепция кэширования и delta-encoding выходит далеко за рамки HTTP.

PD>>Я не буду, конечно, утверждать, что клиент РБД связывается с ней по именно по RPC. Там внизу скорее всего иначе. Но суть от этого не меняется.
PD>>Запросил ты что-то с помощью SELECT и что ? Кто там не изменился и что должно возвращаться ? Нет такого понятия — не изменился. Просил — получи, а потом сам и разбирайся, что там изменилось, а что нет.
S>Ну, так это-то и плохо. Качаем терабайт данных для того, чтобы заменить одну строчку. Павел, ты уверен, что это — лучше, чем HTTP?

А вот тут как ситуация, которую я в свое время программировал, с использованием thrift. Сервер имеет данные, и по ходу действия к ним кое-что может добавить, а иногда удаляет их все и начинает их вырабатывать с начала. До терабайтов там, правда, дело не доходило, но не так уж мало. Естественно, я не делал перекачки всего, брал инкрементально.


S>Если тебе интересно, как сделать change tracking в RDBMS — обращайся. Я участвую в топиках на эту тему в соответствующем форуме в среднем ежегодно


Раз в год ?

Спасибо, понадобится — обращусь.

S>И опять ровно всё — мимо.

S>Сначала для интерфейса со "сложным серверным кодом" начали применять RPC. Потом — RMI. Применение HTTP для этого возникло существенно позже. И, естественно, сначала усилия были вложены в противоположную сторону — люди взяли из HTTP ровно один глагол (самый бесполезный) и завернули RPC/RMI в XML over HTTP.

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

По сути, глаголы HTTP — это CRUD. Не совсем точно, конечно, но в основном. Вот и делается попытка натянуть на CRUD все действия, которые нужны в приложении. Между тем RPC от всего этого свободен. Это просто набор функций/методов, которые делают то, что автору нужно. Как, впрочем, и наборы функций/методов в любых библиотеках и их пакетах/неймспейсах/классах.

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

С RPC все просто — назови функцию как хочешь, передай в ней данные, а там она пусть делает , что там надо, в соответствии с логикой действий. Кстати, обрати внимание вот на что. Довольно странно было бы представить себе дискуссию, в которой обсуждался бы правильный порядок параметров методов. Да, какие-то писаные или неписаные правила есть, вроде того, что handle передается обычно первым параметром, но в остальном — да нечего тут обсуждать, что надо, то и передаем, в какой форме надо, в такой и передаем. А тут целая дискуссия о том, в сущности, как правильно параметры передавать.

HTTP — какой глагол употребим ?

S>RPC тут оказался мимо тазика — во всех его инкарнациях.


RPC, с твоего разрешения, лежит под DCOM/OLE (ты это должен знать), а там гораздо более сложная логика, чем в бизнес-приложениях. Убери RPC — и Windows больше нет.
With best regards
Pavel Dvorkin
Отредактировано 12.02.2020 16:12 Pavel Dvorkin . Предыдущая версия .
Re[11]: REST: прохой\хороший интерфейс
От: Sharov Россия  
Дата: 12.02.20 16:46
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>RPC, с твоего разрешения, лежит под DCOM/OLE (ты это должен знать), а там гораздо более сложная логика, чем в бизнес-приложениях. Убери RPC — и Windows больше нет.


А разве WCF беэ DCOM/OLE не обходится? А rpc там в полный рост.
Кодом людям нужно помогать!
Re[11]: REST: прохой\хороший интерфейс
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.02.20 17:27
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну это обсуждать не стоит. Она есть, она работает.
Неа, не работает. Возникает иллюзия работы. Которая продолжается ровно до первого залетевшего дятла.
Павел, не надо спорить на ровном месте — поверь опыту людей, которые видели и эксплуатировали всякие разные виды API.

PD>На основании существующих рецептов и идей. Которые определяются в значительной мере этой практикой. Попробуй от нее отрешиться и подумай — если бы тебе дали возможность спроектировать протокол заново, ты бы точно сделал HTTP ? Сейчас, зная все, что есть, а не 20 веке.

Нет. Для веб-сайтов сейчас я бы спроектировал HTTP 2.0
Но для API межсерверного взаимодействия HTTP 1.1. совершенно прекрасен. Его очень, очень трудно превзойти — кроме нишевых применений.

PD>А вот тут как ситуация, которую я в свое время программировал, с использованием thrift. Сервер имеет данные, и по ходу действия к ним кое-что может добавить, а иногда удаляет их все и начинает их вырабатывать с начала. До терабайтов там, правда, дело не доходило, но не так уж мало. Естественно, я не делал перекачки всего, брал инкрементально.

Ну вот. При этом инкрементальность приходилось велосипедить самому. И вряд ли удалось сначала сделать протокол без инкрементальности, а потом добавить к нему инкрементальность обратно-совместимым способом.

PD>Раз в год ?

Ну да, сейчас вообще трафик профильных форумов низкий.
PD>Верно, позже. Но я вовсе не сравнивал в этом плане RPC и HTTP. Я просто повторяю — HTTP был не для сложных задач сделан, а для (в основном) статических сайтов, ну , может, с примесью CGI. Не было он сделан как протокол для сложных приложений, которых просто тогда не только не было, а и представить себе никто не мог. Ну а потом начали его натягивать на эти сложные приложения, в итоге имеем что имеем.
В том-то и дело, что начали "натягивать" его уже после того, как попробовали другие подходы. Внезапно оказалось, что он гораздо лучше подходит для сложных приложений, чем любая корба, не говоря уже о SOAP.

PD>По сути, глаголы HTTP — это CRUD. Не совсем точно, конечно, но в основном.

Именно, что совсем.
PD>Вот и делается попытка натянуть на CRUD все действия, которые нужны в приложении. Между тем RPC от всего этого свободен. Это просто набор функций/методов, которые делают то, что автору нужно. Как, впрочем, и наборы функций/методов в любых библиотеках и их пакетах/неймспейсах/классах.
))
Павел, очень, очень советую почитать литературу. Ссылка на бесплатную книжку приведена прямо в этом топике. "Свобода" RPC означает, по большому счёту, свободу писать некорректные и неоптимизируемые протоколы.

PD>Вот ответь мне на такой вопрос. Есть некое действие, которое нужно выполнить. Суть его заключается в добавлении чего-то куда-то на сервере. Однако если при этом возникнет ситуация X, то необходимо на сервере, вместо этого добавления, произвести изменения других существующих там данных или их удаление. Данные для этих изменений/удалений в запросе не передаются, они образуются в результате обработки запроса на добавление и возникновения ситуации X.


PD>С RPC все просто — назови функцию как хочешь, передай в ней данные, а там она пусть делает , что там надо, в соответствии с логикой действий. Кстати, обрати внимание вот на что. Довольно странно было бы представить себе дискуссию, в которой обсуждался бы правильный порядок параметров методов. Да, какие-то писаные или неписаные правила есть, вроде того, что handle передается обычно первым параметром, но в остальном — да нечего тут обсуждать, что надо, то и передаем, в какой форме надо, в такой и передаем. А тут целая дискуссия о том, в сущности, как правильно параметры передавать.

Нет. Дискуссия о том, какие параметры передавать. И логика, привычная разработчикам локальных программ, тут не работает. Это у вас вызов стоит наносекунды, а его обработка — миллисекунды. И он всегда заканчивается детерминированным результатом. А в сети вызов может занимать секунды, а его обработка — миллисекунды. И никогда нет гарантии узнать, завершился ли вызов успешно, или нет.

PD>HTTP — какой глагол употребим ?

С точки зрения HTTP, совершенно неважно, что там происходит "на сервере". Важно то, как мы это представляем клиенту. Representational State Transfer. Если клиенту выставляется такая модель ресурсов, что при применении этого действия к модели добавляется новый ресурс, то делаем через PUT.
На всякий случай поясню, что такие вопросы обсуждать бессмысленно. Конструктивную беседу можно вести только в рамках более-менее очерченной задачи.
Придумай задачу, для которой тебе кажется естественным некий RPC-API (можешь сразу и набросать его черновик), а REST-API вызывает затруднения. Я покажу, как сделать REST для этой задачи, и можно будет сравнить достоинства и недостатки.

PD>RPC, с твоего разрешения, лежит под DCOM/OLE (ты это должен знать), а там гораздо более сложная логика, чем в бизнес-приложениях. Убери RPC — и Windows больше нет.

Я вас умоляю. DCOM/OLE работает в тепличных условиях локальной машины. В нём ситуация "не удалось доставить результат вызова обратно" — редкость. И когда она случается, результат лечат перезагрузкой машины.
Использовать DCOM через океан — упаси байт! Представь себе приложение резервирования авиабилетов, написанное на DCOM. Или хотя бы онлайн-регистрации. Нафиг-нафиг.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: REST: прохой\хороший интерфейс
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.02.20 17:28
Оценка:
Здравствуйте, Sharov, Вы писали:

S>А разве WCF беэ DCOM/OLE не обходится? А rpc там в полный рост.

Тут опять путаница терминологии. RPC, который в WCF — это общий термин, стиль работы API. А RPC в DCOM — это конкретная технология маршаллинга.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: REST: прохой\хороший интерфейс
От: Sharov Россия  
Дата: 12.02.20 18:12
Оценка: +1
Здравствуйте, Sinclair, Вы писали:


S>На всякий случай поясню, что такие вопросы обсуждать бессмысленно. Конструктивную беседу можно вести только в рамках более-менее очерченной задачи.

S>Придумай задачу, для которой тебе кажется естественным некий RPC-API (можешь сразу и набросать его черновик), а REST-API вызывает затруднения. Я покажу, как сделать REST для этой задачи, и можно будет сравнить достоинства и недостатки.

Влезу. Ну, например, калькулятор, который на удаленной машине чего-то считает. rpc прямолинеен, а вот с rest придется попотеть. Вообще, как я понимаю, rest нужен, когда мы имеем дело
с необходимостью CRUD чего-то. Если нам просто нужны чьи-то выч. ресурсы и время, без соотв. crud, то rpc вполне подойдет.
Кодом людям нужно помогать!
Re[13]: REST: прохой\хороший интерфейс
От: · Великобритания  
Дата: 12.02.20 22:27
Оценка:
Здравствуйте, Sharov, Вы писали:

S>>На всякий случай поясню, что такие вопросы обсуждать бессмысленно. Конструктивную беседу можно вести только в рамках более-менее очерченной задачи.

S>>Придумай задачу, для которой тебе кажется естественным некий RPC-API (можешь сразу и набросать его черновик), а REST-API вызывает затруднения. Я покажу, как сделать REST для этой задачи, и можно будет сравнить достоинства и недостатки.
S>Влезу. Ну, например, калькулятор, который на удаленной машине чего-то считает. rpc прямолинеен, а вот с rest придется попотеть. Вообще, как я понимаю, rest нужен, когда мы имеем дело
S>с необходимостью CRUD чего-то. Если нам просто нужны чьи-то выч. ресурсы и время, без соотв. crud, то rpc вполне подойдет.
Калькулятор это stateless — скучно и тривиально, решается одинаково просто практически на чём угодно левой пяткой во сне. А REST это всё-таки Representational state transfer.

Хотя даже в таком случае — когда ты начнёшь задавать вопрос как передавать состояние "сервер сломался", "клиент корявое выражение послал", "серверу от напора клиентов поплохело, надо бы им как-то объяснить, чтобы не ломились так часто", "а в каком виде будем договариваться в каком виде передавать выражение — xml/json/whatever?", "а как договориться о формате компрессии?", "а как обеспечить секьюрную передачу инфы?". Все эти вопросы тебе придётся колхозить практически в любой существующей RPC-технологии, когда как в REST это всё из коробки и прикручивается тривиально.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Отредактировано 12.02.2020 22:32 · . Предыдущая версия . Еще …
Отредактировано 12.02.2020 22:27 · . Предыдущая версия .
Re[14]: REST: прохой\хороший интерфейс
От: Sharov Россия  
Дата: 12.02.20 22:41
Оценка:
Здравствуйте, ·, Вы писали:

S>>Влезу. Ну, например, калькулятор, который на удаленной машине чего-то считает. rpc прямолинеен, а вот с rest придется попотеть. Вообще, как я понимаю, rest нужен, когда мы имеем дело

S>>с необходимостью CRUD чего-то. Если нам просто нужны чьи-то выч. ресурсы и время, без соотв. crud, то rpc вполне подойдет.
·>Калькулятор это stateless — скучно и тривиально, решается одинаково просто практически на чём угодно левой пяткой во сне. А REST это всё-таки Representational state transfer.

Нам не нужен state, я же написал об этом. Нам нужны выч. ресурсы -- закинул задачу и пошел себе дальше.
Кодом людям нужно помогать!
Re[15]: REST: прохой\хороший интерфейс
От: · Великобритания  
Дата: 12.02.20 22:57
Оценка:
Здравствуйте, Sharov, Вы писали:

S>·>Калькулятор это stateless — скучно и тривиально, решается одинаково просто практически на чём угодно левой пяткой во сне. А REST это всё-таки Representational state transfer.

S>Нам не нужен state, я же написал об этом. Нам нужны выч. ресурсы -- закинул задачу и пошел себе дальше.
Т.е. код примерно такой:
try
{
    result = remote.calculator(expression);
}
catch(RemoteException e) {
    //do what??
}

Вот уже надо как-то отличать типы RemoteException чтобы либо показать пользователю "у вас тут что-то не так" или "сервер занят. Повторить?".

Да, я ещё там в своё сообщение параграф вставил, ты видимо не заметил.

Хотя даже в таком случае — когда ты начнёшь задавать вопрос как передавать состояние "сервер сломался", "клиент корявое выражение послал", "серверу от напора клиентов поплохело, надо бы им как-то объяснить, чтобы не ломились так часто", "а в каком виде будем договариваться в каком виде передавать выражение — xml/json/whatever?", "а как договориться о формате компрессии?", "а как обеспечить секьюрную передачу инфы?". Все эти вопросы тебе придётся колхозить практически в любой существующей RPC-технологии, когда как в REST это всё из коробки и прикручивается тривиально.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[14]: REST: прохой\хороший интерфейс
От: samius Япония http://sams-tricks.blogspot.com
Дата: 12.02.20 23:37
Оценка: 6 (1)
Здравствуйте, ·, Вы писали:

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


S>>Влезу. Ну, например, калькулятор, который на удаленной машине чего-то считает. rpc прямолинеен, а вот с rest придется попотеть. Вообще, как я понимаю, rest нужен, когда мы имеем дело

S>>с необходимостью CRUD чего-то. Если нам просто нужны чьи-то выч. ресурсы и время, без соотв. crud, то rpc вполне подойдет.
·>Калькулятор это stateless — скучно и тривиально, решается одинаково просто практически на чём угодно левой пяткой во сне. А REST это всё-таки Representational state transfer.

Есть таки ощущение неверной трактовки слова "state" в аббревиатуре REST. Речь вовсе не о том, как мы будем менять состояние на сервере, и будем ли вообще. Вот что пишет об этом Филдинг:

REST was originally referred to as the "HTTP object model," but that name would often lead to misinterpretation of it as the implementation model of an HTTP server. The name "Representational State Transfer" is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through the application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use.


То есть, по-крайней мере название REST — это о том, как клиент хранит состояние сессии. Но, конечно, REST не ограничивается одной лишь этой идеей, в списке идей источников присутствует Remote Session.
Re[13]: REST: прохой\хороший интерфейс
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.02.20 03:22
Оценка:
Здравствуйте, Sharov, Вы писали:

S>Влезу. Ну, например, калькулятор, который на удаленной машине чего-то считает. rpc прямолинеен, а вот с rest придется попотеть.

Даже напрячься не успеем.
GET /calculate?expression=((1800*999)-677)/65866556

Более интересный пример:
GET /factor?number=568132681318943132168430


Пример калькулятора, который на удаленной машине чего-то считает, в котором REST выигрывает у RPC:
GET /pi
Range: bytes 0-1000

Этот запрос может быть отдан из кэша любым промышленным прокси-сервером.

Вообще, как я понимаю, rest нужен, когда мы имеем дело
S>с необходимостью CRUD чего-то. Если нам просто нужны чьи-то выч. ресурсы и время, без соотв. crud, то rpc вполне подойдет.
REST нужен тогда, когда мы работаем с разделяемым состоянием.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[15]: REST: прохой\хороший интерфейс
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.02.20 03:33
Оценка:
Здравствуйте, Sharov, Вы писали:
S>Нам не нужен state, я же написал об этом. Нам нужны выч. ресурсы -- закинул задачу и пошел себе дальше.
Вот прямо отличный пример. "Пошёл себе дальше" подразумевает, наверное, возможность как-то потом забрать результат, так?
Значит, у нас появляется сущность "задача", и её состояние: "в очереди", "в процессе выполнения", "выполнена", "сбой выполнения". Это состояние нужно синхронизовывать между клиентом и сервером.
Всё, REST начинает выигрывать у RPC ещё до начала забега — как раз потому, что он позволяет внятно описать CRUD над множеством задач. Ваши первые две-три реализации RPC будут страдать от детских болезней вроде "нечаянно поставил одну и ту же задачу в очередь дважды" или "задачу поставил — результат потерял".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: REST: прохой\хороший интерфейс
От: Pavel Dvorkin Россия  
Дата: 13.02.20 03:45
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ну вот. При этом инкрементальность приходилось велосипедить самому. И вряд ли удалось сначала сделать протокол без инкрементальности, а потом добавить к нему инкрементальность обратно-совместимым способом.


Инкрементальность была заложена задачей, поэтому проектировалось с ней сразу.

S>Павел, очень, очень советую почитать литературу. Ссылка на бесплатную книжку приведена прямо в этом топике. "Свобода" RPC означает, по большому счёту, свободу писать некорректные и неоптимизируемые протоколы.


Спасибо за совет

PD>>HTTP — какой глагол употребим ?

S>С точки зрения HTTP, совершенно неважно, что там происходит "на сервере". Важно то, как мы это представляем клиенту. Representational State Transfer. Если клиенту выставляется такая модель ресурсов, что при применении этого действия к модели добавляется новый ресурс, то делаем через PUT.
S>На всякий случай поясню, что такие вопросы обсуждать бессмысленно. Конструктивную беседу можно вести только в рамках более-менее очерченной задачи.
S>Придумай задачу, для которой тебе кажется естественным некий RPC-API (можешь сразу и набросать его черновик), а REST-API вызывает затруднения. Я покажу, как сделать REST для этой задачи, и можно будет сравнить достоинства и недостатки.

Пожалуйста. Сразу прошу прощения за небольшие отклонения от классика , сделаны для пущей выразительности.

На сервер города N добавляется новая Персона. Все, что о ней известно на момент ее поступления на сервер — инкогнито, недурной наружности, в партикулярном платье, ходит этак по комнате, и в лице этакое рассуждение... физиономия... поступки, и здесь (вертит рукою около лба) много, много всего.
С использованием методов машинного интеллекта при участии персон Городничего, Ляпкина-Тяпкина, Добчинского и Бобчинского производится классификация этой Персоны — относится ли она к категории Ревизоры
Если эта классификация отнесет его к категории Ревизор, то необходимо
1. Надеть колпаки на больных в богоугодном заведении и проследить, чтобы они были чистыми
2. Сделать, чтобы больные не походили бы на кузнецов
3. Над каждой кроватью написать по-латыни название болезни
4. Удалить всех гусей с гусенками из присутственных мест, а также удалить охотничий арапник там же
5. Провести воспитательную беседу с учителями (алгоритм TBD) и особо им указать, чтобы стулья не ломали
6. Сказать Держиморде, чтобы не слишком давал воли кулакам своим
7. Подготовить некую сумму денег для взятки.

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

Если же он не Ревизор, то все, что надо — записать его в книгу проезжающих и предоставить собственной судьбе.

Так что же это — POST, PUT или DELETE ? И чего именно ?

Для RPC —

class Person {
String наружность;
String платье;
//...
}

void addPerson(Person person);

а там уж что будет, то и будет.


PD>>RPC, с твоего разрешения, лежит под DCOM/OLE (ты это должен знать), а там гораздо более сложная логика, чем в бизнес-приложениях. Убери RPC — и Windows больше нет.

S>Я вас умоляю. DCOM/OLE работает в тепличных условиях локальной машины. В нём ситуация "не удалось доставить результат вызова обратно" — редкость. И когда она случается, результат лечат перезагрузкой машины.

COM работает в условиях локальной машины, а DCOM — это Distributed COM, работает в локальной сети.

S>Использовать DCOM через океан — упаси байт! Представь себе приложение резервирования авиабилетов, написанное на DCOM. Или хотя бы онлайн-регистрации. Нафиг-нафиг.


Причин же, почему DCOM для этого не используется , три

1. HTTP был сделан раньше, вот его и продолжвли использовать
2. COM нет в линуксе, что сразу ставит крест на возможности его использования для этой цели
3. COM не подерживают все браузеры даже в Windows.
With best regards
Pavel Dvorkin
Отредактировано 13.02.2020 4:22 Pavel Dvorkin . Предыдущая версия .
Re[13]: REST: прохой\хороший интерфейс
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.02.20 04:19
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

S>>С точки зрения HTTP, совершенно неважно, что там происходит "на сервере". Важно то, как мы это представляем клиенту. Representational State Transfer. Если клиенту выставляется такая модель ресурсов, что при применении этого действия к модели добавляется новый ресурс, то делаем через PUT.

S>>На всякий случай поясню, что такие вопросы обсуждать бессмысленно. Конструктивную беседу можно вести только в рамках более-менее очерченной задачи.
S>>Придумай задачу, для которой тебе кажется естественным некий RPC-API (можешь сразу и набросать его черновик), а REST-API вызывает затруднения. Я покажу, как сделать REST для этой задачи, и можно будет сравнить достоинства и недостатки.

PD>Пожалуйста. Сразу прошу прощения за небольшие отклонения от классика , сделаны для пущей выразительности.

PD>Так что же это — POST, PUT или DELETE ? И чего именно ?
Ага. Вижу, набросать RPC вариант сходу не удалось. Лучше бы, конечно, состряпать инженерную задачу, а не Гоголя цитировать, но даже так подойдёт.
Ладно, в REST это будет PUT ресурса "персона".
В RPC у нас сразу возникают вопросы:
— что, если вызов вашего метода так и не вернул ничего? Что нам делать дальше?
— Нужно ли пробовать его ещё раз, и если да, то где гарантия, что по городу не начнут бродить N ревизоров одновременно?

PD>COM работает в условиях локальной машины, а DCOM — это Distributed COM, работает в локальной сети.

Я в курсе.
S>>Использовать DCOM через океан — упаси байт! Представь себе приложение резервирования авиабилетов, написанное на DCOM. Или хотя бы онлайн-регистрации. Нафиг-нафиг.
PD>Причин же, почему DCOM для этого не используется , три
PD>1. HTTP был сделан раньше, вот его и продолжвли использовать
PD>2. COM нет в линуксе, что сразу ставит крест на возможности его использования для этой цели
PD>3. COM не подерживают все браузеры даже в Windows.
Ок, попробую объяснить помедленнее. Отбросим вопрос с браузером. Предположим, мы пишем с нуля систему типа aviasales.ru. Сервер — на винде (мы выбираем, так что можем ставить всё, что захотим). Клиенты — десктопное приложение на винде.
Можно попробовать работать в одном из очевидных стилей:
1. Пишем локальное приложение. Клиенты заходят по RDP и запускают его на сервере терминалов.
3. Пишем клиент-сервер на SQL. Клиенты подключаются прямо к СУБД по 1433
2. Пишем трёхзвенку на DCOM
3. Пишем трёхзвенку на REST
Как ты думаешь, какой из стилей обеспечит лучшую масштабируемость, надёжность, и стоимость внесения изменений при одинаковом железе?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: REST: прохой\хороший интерфейс
От: Pavel Dvorkin Россия  
Дата: 13.02.20 04:37
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ага. Вижу, набросать RPC вариант сходу не удалось.


Нет, просто забыл. Добавил там.

Лучше бы, конечно, состряпать инженерную задачу, а не Гоголя цитировать, но даже так подойдёт.
S>Ладно, в REST это будет PUT ресурса "персона".

Хм, а почему же PUT ? Может , все же POST ? Ведь не было же там его, что же меняем ?

S>В RPC у нас сразу возникают вопросы:

S>- что, если вызов вашего метода так и не вернул ничего? Что нам делать дальше?
S>- Нужно ли пробовать его ещё раз, и если да, то где гарантия, что по городу не начнут бродить N ревизоров одновременно?

А он и не должен ничего возвращать. В данной версии не предусмотрено, это что-то вроде UDP, потому что в Ревизоре ничего толком не сказано о том, кто посылает (туманное именное повеление — вот и все). Если же нужно — метод должен выбросить исключение, и автор именного повеления примет решение, что делать. Например, если было исключение RevisorKilledException, то, возможно, надо послать туда следователей

S>Ок, попробую объяснить помедленнее. Отбросим вопрос с браузером. Предположим, мы пишем с нуля систему типа aviasales.ru. Сервер — на винде (мы выбираем, так что можем ставить всё, что захотим). Клиенты — десктопное приложение на винде.

S>Можно попробовать работать в одном из очевидных стилей:
S>1. Пишем локальное приложение. Клиенты заходят по RDP и запускают его на сервере терминалов.
S>3. Пишем клиент-сервер на SQL. Клиенты подключаются прямо к СУБД по 1433
S>2. Пишем трёхзвенку на DCOM
S>3. Пишем трёхзвенку на REST
S>Как ты думаешь, какой из стилей обеспечит лучшую масштабируемость, надёжность, и стоимость внесения изменений при одинаковом железе?

Первое и второе обсуждать незачем.
А вот третье и четвертое — зависит от того, насколько качественно будет реализовано.
With best regards
Pavel Dvorkin
Re[14]: REST: прохой\хороший интерфейс
От: Буравчик Россия  
Дата: 13.02.20 06:19
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Даже напрячься не успеем.

S>
S>GET /calculate?expression=((1800*999)-677)/65866556
S>


А если мы делаем "платный прогноз погоды"?
Пользователю доступно не более 10 запросов в месяц.
Операции: getWeather (получение погоды) и getStats (количество неиспользованных запросов)
Best regards, Буравчик
Re[15]: REST: прохой\хороший интерфейс
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.02.20 06:50
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Хм, а почему же PUT ? Может , все же POST ? Ведь не было же там его, что же меняем ?

Потому, что с PUT нам проще обеспечить идемпотентность. Ненадёжная RPC-реализация, очевидно, предложена не от глубокого понимания ограничений задачи, а просто от некомпететности.
REST-реализация позволяет нам решить проблему двух генералов: в случае потери коммуникации мы будем отправлять туда ревизора столько раз, сколько потребуется — и иметь гарантию его единственности:
PUT /person/12123743120912312
If-None-Match: * 

{
 "наружность": "недурная",
 "платье": "партикулярное",
 ...
}

Проблемы с POST уже описаны в параллельной ветке: https://rsdn.org/forum/design/7653493.1
Автор: Sinclair
Дата: 10.02.20


PD>А он и не должен ничего возвращать. В данной версии не предусмотрено, это что-то вроде UDP, потому что в Ревизоре ничего толком не сказано о том, кто посылает (туманное именное повеление — вот и все).

Прекрасно, Павел. С тем же успехом можно просто писать в dev/null — ведь
а) предлагаемый вами метод имеет тип void, т.е. результат не нужен
б) механизмов контроля того, что вызов произвёл хоть какие-то побочные эффекты, тоже не предусмотрено.
А раз клиента это устраивает — чего и огород городить? Сервер какой-то писать. dev/null полностью удовлетворяет заданной спецификации, и требует 0 затрат на разработку и поддержку.
Нет, надо что-то ещё? Ну так значит садитесь и изобретайте ключи идемпотентности, политику retry. Придумывайте, как вы будете оповещать клиентов о миграции ендпоинта на новый адрес.
Что делать, если придёт запрос с тем же ключом идемпотентности, но с другим содержимым.
RPC провоцирует людей делать стрёмные протоколы. Причём если в REST, к примеру, архитектор и девелопер тупили и сделали первую версию криво, то вторую можно просто починить.
То есть не меняем спецификацию протокола, а меняем поведение — с некорректного на корректное. И всё, всё начинает работать.
В RPC придётся менять сигнатуры методов, а это очень, очень дорогое удовольствие.
Вам ещё повезёт, если вместо убогого DCOM был выбран какой-то более гибкий RPC протокол, например XML-RPC. Там хотя бы можно добавлять к существующим вызовам необязательные параметры, сохраняя обратную совместимость.
А с DCOM или классическим RPC проект умрёт ещё до выхода в продакшн.

PD>Если же нужно — метод должен выбросить исключение, и автор именного повеления примет решение, что делать. Например, если было исключение RevisorKilledException, то, возможно, надо послать туда следователей

Вот она, ущербность RPC-мышления в полный рост. Привычка к гарантии того, что исключение достигнет соответствующего catch-блока, взятая из локальных вызовов процедур.
Сеть устроена не так — метод-то может что-то и выкинет, но далеко не факт, что клиент что-то поймает. Ревизора убили, в городе война с турками, казна разворована на взятки.
Ни о чём из этого клиент не узнаёт — просто вызов получил в ответ RPC_E_TIMEOUT.

S>>1. Пишем локальное приложение. Клиенты заходят по RDP и запускают его на сервере терминалов.

S>>3. Пишем клиент-сервер на SQL. Клиенты подключаются прямо к СУБД по 1433
S>>2. Пишем трёхзвенку на DCOM
S>>3. Пишем трёхзвенку на REST
S>>Как ты думаешь, какой из стилей обеспечит лучшую масштабируемость, надёжность, и стоимость внесения изменений при одинаковом железе?

PD>Первое и второе обсуждать незачем.

PD>А вот третье и четвертое — зависит от того, насколько качественно будет реализовано.
Вспотеешь ты "качественно реализовывать" DCOM. Построить REST-сервер, который обслуживает пару десятков тысяч клиентов одновременно, можно не выходя из режима "скопировал демку со stackoverflow".
DCOM-сервер будет дохнуть на нагрузках примерно в тысячу раз меньше. Нет, его можно будет подпилить так, чтобы проигрыш был всего на порядок, но к этому моменту бюджет уже закончится.
Это в предположении, что архитектор был настолько квалифицирован, что сумел сразу предусмотреть все механизмы кэширования, восстановления после сбоев, обработки конфликтов и прочего — что в REST идёт из коробки.
В обычном случае получим многопользовательскую систему на 10-100 пользователей, и любые попытки масштабировать её хотя бы в 100 раз приведут к выбросу и замене на веб-приложение.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[15]: REST: прохой\хороший интерфейс
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.02.20 06:52
Оценка:
Здравствуйте, Буравчик, Вы писали:
Б>А если мы делаем "платный прогноз погоды"?
Б>Пользователю доступно не более 10 запросов в месяц.
Б>Операции: getWeather (получение погоды) и getStats (количество неиспользованных запросов)
GET /weather

GET /stats

Что именно вызывает затруднения?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: REST: прохой\хороший интерфейс
От: night beast СССР  
Дата: 13.02.20 07:00
Оценка:
Здравствуйте, Sinclair, Вы писали:

Б>>А если мы делаем "платный прогноз погоды"?

Б>>Пользователю доступно не более 10 запросов в месяц.
Б>>Операции: getWeather (получение погоды) и getStats (количество неиспользованных запросов)
S>GET /weather

здесь request_id не нужен?
Re[17]: REST: прохой\хороший интерфейс
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.02.20 07:09
Оценка:
Здравствуйте, night beast, Вы писали:
NB>здесь request_id не нужен?
Вот недостаточно данных. Потому что непонятно, как подсчитывать количество запросов в месяц: считать ли "одинаковые" результаты "разными" запросами, или одним и тем же?
Если разными, то считаем ли мы 304 за такой запрос, или нет?
Что заставляет пользователя повторять запросы — там меняются какие-то параметры, или меняется сама погода?

Обычно подобные ограничения на API ставят на стороне сервера; плохая коммуникация считается проблемой клиента. Просто при превышении лимита клиент получает 503 с соответствующим Retry-After, а злонамеренное игнорирование Retry-After приводит к бану аккаунта.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.