Сообщение Re[10]: REST: прохой\хороший интерфейс от 12.02.2020 15:31
Изменено 12.02.2020 16:12 Pavel Dvorkin
Re[10]: REST: прохой\хороший интерфейс
Здравствуйте, 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 все просто — назови функцию как хочешь, передай в ней данные, а там она пусть делает , что там надо, в соответствии с логикой действий.
HTTP — какой глагол употребим ?
S>RPC тут оказался мимо тазика — во всех его инкарнациях.
RPC, с твоего разрешения, лежит под DCOM/OLE (ты это должен знать), а там гораздо более сложная логика, чем в бизнес-приложениях. Убери RPC — и Windows больше нет.
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 все просто — назови функцию как хочешь, передай в ней данные, а там она пусть делает , что там надо, в соответствии с логикой действий.
HTTP — какой глагол употребим ?
S>RPC тут оказался мимо тазика — во всех его инкарнациях.
RPC, с твоего разрешения, лежит под DCOM/OLE (ты это должен знать), а там гораздо более сложная логика, чем в бизнес-приложениях. Убери RPC — и Windows больше нет.
Re[10]: REST: прохой\хороший интерфейс
Здравствуйте, 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 больше нет.
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 больше нет.