Сообщение Re[13]: REST: прохой\хороший интерфейс от 12.02.2020 22:27
Изменено 12.02.2020 22:32 ·
Re[13]: REST: прохой\хороший интерфейс
Здравствуйте, Sharov, Вы писали:
S>>На всякий случай поясню, что такие вопросы обсуждать бессмысленно. Конструктивную беседу можно вести только в рамках более-менее очерченной задачи.
S>>Придумай задачу, для которой тебе кажется естественным некий RPC-API (можешь сразу и набросать его черновик), а REST-API вызывает затруднения. Я покажу, как сделать REST для этой задачи, и можно будет сравнить достоинства и недостатки.
S>Влезу. Ну, например, калькулятор, который на удаленной машине чего-то считает. rpc прямолинеен, а вот с rest придется попотеть. Вообще, как я понимаю, rest нужен, когда мы имеем дело
S>с необходимостью CRUD чего-то. Если нам просто нужны чьи-то выч. ресурсы и время, без соотв. crud, то rpc вполне подойдет.
Калькулятор это stateless — скучно и тривиально, решается одинаково просто практически на чём угодно левой пяткой во сне. А REST это всё-таки Representational state transfer.
S>>На всякий случай поясню, что такие вопросы обсуждать бессмысленно. Конструктивную беседу можно вести только в рамках более-менее очерченной задачи.
S>>Придумай задачу, для которой тебе кажется естественным некий RPC-API (можешь сразу и набросать его черновик), а REST-API вызывает затруднения. Я покажу, как сделать REST для этой задачи, и можно будет сравнить достоинства и недостатки.
S>Влезу. Ну, например, калькулятор, который на удаленной машине чего-то считает. rpc прямолинеен, а вот с rest придется попотеть. Вообще, как я понимаю, rest нужен, когда мы имеем дело
S>с необходимостью CRUD чего-то. Если нам просто нужны чьи-то выч. ресурсы и время, без соотв. crud, то rpc вполне подойдет.
Калькулятор это stateless — скучно и тривиально, решается одинаково просто практически на чём угодно левой пяткой во сне. А REST это всё-таки Representational state transfer.
Re[13]: REST: прохой\хороший интерфейс
Здравствуйте, 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 это всё из коробки и прикручивается тривиально.
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 это всё из коробки и прикручивается тривиально.