То, что запрос начал обрабатываться раньше, чем были переданы все его параметры, не делает запрос асинхронным.
Клиент в любом случае будет ждать начала передачи ответа или его части для начала обработки (даже если это потоковая передача данных). И, как правило, проблема совсем не в длительной отправке запроса, а в длительном ожидании начала ответа (пока работает бизнес-логика). В этом случае передача данных потоком никак вам не поможет.
Спасибо за ссылку на документацию! Открываем её и видим утверждение:
"…REST does not restrict communication to a particular protocol…"
И оно верное, но с оговоркой, которая следует дальше:
"…but it does constrain the interface between components…"
Чуть выше, в разделе 5.2.2, как раз и упоминается одно из таких ограничений:
"…From an abstract viewpoint the invocation is synchronous, but both in and out-parameters can be passed as data streams…"
, из-за которого в классическом REST, в отличие от JSON-RPC, вы не сможете сделать асинхронное взаимодействие с ресурсами даже при выборе транспорта, отличного от HTTP. Разумеется, асинхронное взаимодействие можно сделать для своей реализации, но для этой технологии это будет костыль, тогда как в JSON-RPC это будет работать нативно.
Спасибо за развернутый ответ, и мы рады, что получается конструктивная дискуссия, но все же вы вырвали из контекста описание метода JSONRPCResponseManager.handle. Вот как звучит его полное описание:
Method brings syntactic sugar into library. Given dispatcher it handles request (both single and batch) and handles errors. Request could be handled in parallel, it is server responsibility.
что в дословном переводе
Метод добавляет синтаксический сахар в библиотеку. Учитывая диспетчер, он обрабатывает запрос (как одиночный, так и пакетный) и обрабатывает ошибки. Запрос может обрабатываться параллельно, это ответственность сервера.
Этот метод принимает запрос, валидирует его на предмет корректности JSON-RPC, вызывает метод handle_request, который, собственно, и отправляет его в бизнес-логику (dispatcher), принимает ответ от бизнес-логики, форматирует ответ по спецификации JSON-RPC и возвращает респонс. Именно это определение для хэндлера вы и дали.
Возможно, вы путаете валидацию запроса (некорректный запрос, вызов несуществующего метода или ошибку в параметрах и т. п.) и валидацию непосредственно параметров, с которыми вызывается удаленный метод (а такую валидацию, как мы писали ранее, необходимо делать при выборе любой технологии)
Что касается предложения "сделать класс, внего поместить все хендлеры, потом пробежаться по методам класса и router.add_api_route добавить хендлеры в роутер" — так это как раз и есть RPC, который сделали для FastAPI. На самом деле, технологии REST и RPC очень близки, особенно когда часть технологии RPC интегрируют в классический REST. Но это и есть костыли к REST.
В данной ситуации JSONRPCResponseManager.handle — это и есть хэндлер запроса, в то время как при вызовах методов dispatcher нет никакого указания на то, что методы в нем должны быть ещё одними хэндлерами.
Спасибо за ссылку, это интересная статья, но всё же в ней приведено неполное и довольно однобокое сравнение технологий.
Так, вам будет очень сложно объединить несколько операций в транзакцию с возможностью отката, оставаясь при этом в архитектуре отдельных объектов REST.
Спасибо за развёрнутое мнение! Сложилось впечатление, что вы смотрите на RPC через призму REST и потому не придаёте значения некоторым различиям (а они есть).
Так, в случае RPC класс Users — это не handler, а бизнес-логика. Метод, добавленный в класс, автоматически будет доступен в API (и, например, для повторного использования в проекте). Создав метод нативными средствами языка, вы избавляетесь от необходимости делать что-то для API: RPC-сервер проверит корректность вызова метода и переданных параметров, и в случае некорректного вызова сам вернет ошибку без вашего участия. Разумеется, не стоит путать проверку корректности вызова и валидацию или санацию входных данных. Эта часть будет при любой выбранной архитектуре.
P.S. ваш совет о gRPC хорош и разумен, но эта технология тяжело встает на legacy-проект (у нас именно этот случай). Хотя, очень вероятно, в будущем мы как раз на gRPC и перейдем.
GraphQL — язык запросов, а не архитектурный стиль. Это тоже и управление, и передача состояния — но в статье мы пишем несколько о другом: здесь мы сравниваем только классический RESTful API и JSON-RPC 2.0. Сравнивать всё со всем (если мы правильно понимаем, что вы предлагаете) — это объём материала на несколько книг, а не одну статью на Хабре.
RESTful API — архитектура, которая базируется на HTTP, а все остальные, как вы выражаетесь, «элементарные фасады» — как раз и есть ресурсы, которые мы бы тратили на доработку там, где JSON-RPC работает из коробки.
Ваше утверждение о том, что Django и FastAPI — это «кривые фреймворки», мягко говоря, не выдерживает критики.
В остальном спасибо за внимание и желаем хорошего дня!
Мы описываем кейс, когда у пользователя нет возможности развернуть собственный bare-metal server — если у вас он есть в доступе, ситуация может быть и другой.
Мы говорим о закрытом перечне из 9 уязвимостей, которые были актуальны именно для нас, статистика приведена по этому перечню — и да, в нашем случае цифры получились именно такими.
Подробно разбираем здесь не каждую из этих уязвимостей, так как целью текста ставили не подробный их разбор, а хотели подчеркнуть эффективность обучения. Но если вам интересны подробности по конкретным уязвимостям, мы можем посвятить этому один из следующих постов☺
То, что запрос начал обрабатываться раньше, чем были переданы все его параметры, не делает запрос асинхронным.
Клиент в любом случае будет ждать начала передачи ответа или его части для начала обработки (даже если это потоковая передача данных). И, как правило, проблема совсем не в длительной отправке запроса, а в длительном ожидании начала ответа (пока работает бизнес-логика). В этом случае передача данных потоком никак вам не поможет.
Спасибо за ссылку на документацию! Открываем её и видим утверждение:
И оно верное, но с оговоркой, которая следует дальше:
Чуть выше, в разделе 5.2.2, как раз и упоминается одно из таких ограничений:
, из-за которого в классическом REST, в отличие от JSON-RPC, вы не сможете сделать асинхронное взаимодействие с ресурсами даже при выборе транспорта, отличного от HTTP. Разумеется, асинхронное взаимодействие можно сделать для своей реализации, но для этой технологии это будет костыль, тогда как в JSON-RPC это будет работать нативно.
Спасибо за развернутый ответ, и мы рады, что получается конструктивная дискуссия, но все же вы вырвали из контекста описание метода JSONRPCResponseManager.handle. Вот как звучит его полное описание:
что в дословном переводе
Этот метод принимает запрос, валидирует его на предмет корректности JSON-RPC, вызывает метод handle_request, который, собственно, и отправляет его в бизнес-логику (dispatcher), принимает ответ от бизнес-логики, форматирует ответ по спецификации JSON-RPC и возвращает респонс. Именно это определение для хэндлера вы и дали.
Возможно, вы путаете валидацию запроса (некорректный запрос, вызов несуществующего метода или ошибку в параметрах и т. п.) и валидацию непосредственно параметров, с которыми вызывается удаленный метод (а такую валидацию, как мы писали ранее, необходимо делать при выборе любой технологии)
Что касается предложения "сделать класс, в него поместить все хендлеры, потом пробежаться по методам класса и router.add_api_route добавить хендлеры в роутер" — так это как раз и есть RPC, который сделали для FastAPI. На самом деле, технологии REST и RPC очень близки, особенно когда часть технологии RPC интегрируют в классический REST. Но это и есть костыли к REST.
В данной ситуации JSONRPCResponseManager.handle — это и есть хэндлер запроса, в то время как при вызовах методов dispatcher нет никакого указания на то, что методы в нем должны быть ещё одними хэндлерами.
Пруфы и подробности — в самом коде JSONRPCResponseManager: https://github.com/pavlov99/json-rpc/blob/master/jsonrpc/manager.py
Спасибо за ссылку на пример, он уместен. Но нет ли такого, что вы превратили REST в PRC, который обслуживает 4 метода: GET, POST, PUT и DELETE?
Спасибо за ссылку, это интересная статья, но всё же в ней приведено неполное и довольно однобокое сравнение технологий.
Так, вам будет очень сложно объединить несколько операций в транзакцию с возможностью отката, оставаясь при этом в архитектуре отдельных объектов REST.
Спасибо за развёрнутое мнение! Сложилось впечатление, что вы смотрите на RPC через призму REST и потому не придаёте значения некоторым различиям (а они есть).
Так, в случае RPC класс Users — это не handler, а бизнес-логика. Метод, добавленный в класс, автоматически будет доступен в API (и, например, для повторного использования в проекте). Создав метод нативными средствами языка, вы избавляетесь от необходимости делать что-то для API: RPC-сервер проверит корректность вызова метода и переданных параметров, и в случае некорректного вызова сам вернет ошибку без вашего участия. Разумеется, не стоит путать проверку корректности вызова и валидацию или санацию входных данных. Эта часть будет при любой выбранной архитектуре.
P.S. ваш совет о gRPC хорош и разумен, но эта технология тяжело встает на legacy-проект (у нас именно этот случай). Хотя, очень вероятно, в будущем мы как раз на gRPC и перейдем.
Доброго вечера!
GraphQL — язык запросов, а не архитектурный стиль. Это тоже и управление, и передача состояния — но в статье мы пишем несколько о другом: здесь мы сравниваем только классический RESTful API и JSON-RPC 2.0. Сравнивать всё со всем (если мы правильно понимаем, что вы предлагаете) — это объём материала на несколько книг, а не одну статью на Хабре.
RESTful API — архитектура, которая базируется на HTTP, а все остальные, как вы выражаетесь, «элементарные фасады» — как раз и есть ресурсы, которые мы бы тратили на доработку там, где JSON-RPC работает из коробки.
Ваше утверждение о том, что Django и FastAPI — это «кривые фреймворки», мягко говоря, не выдерживает критики.
В остальном спасибо за внимание и желаем хорошего дня!
Мы описываем кейс, когда у пользователя нет возможности развернуть собственный bare-metal server — если у вас он есть в доступе, ситуация может быть и другой.
Спасибо за вопрос!
Мы говорим о закрытом перечне из 9 уязвимостей, которые были актуальны именно для нас, статистика приведена по этому перечню — и да, в нашем случае цифры получились именно такими.
Подробно разбираем здесь не каждую из этих уязвимостей, так как целью текста ставили не подробный их разбор, а хотели подчеркнуть эффективность обучения. Но если вам интересны подробности по конкретным уязвимостям, мы можем посвятить этому один из следующих постов☺
да, вы правы, а мы были невнимательны: latency увеличивается (но увеличение по bandwith кратно перекрывает увеличение latency)
спасибо за внимательность!