REST или Json-RPC для большого проекта?

Question

[vitalvas]

Нужно написать приложения в котором коммуникация фронтенда и бекенда будет построена по API.
Технологический стек: фронтенд - python, бекенд - golang. Фронтенд не хранит состояния.
По сути - нужна модель CRUD. На сколько сейчас актуально использовать json-rpc?
При этом нужно учитывать что методов или урлов будет несколько сотен.

Answer 1

[al_gon]

По сути своей CRUD ресурсоориентированна.
То что вы описываете подталкивает к REST. Допилите Вы её до абсолютной RESTful это другой вопрос.
Если из несколько сотен методов будет >50% для реализации CRUD . Тогда точно REST.

Аргументация от linkedin:
https://www.linkedin.com/pulse/rest-vs-rpc-soa-sho...

Answer 2

[Сергей Протько]

json rpc - это когда все запросы post.

rest же, это стиль архитектуры. Он не про урлы и не про http. Просто на http он ложится очень неплохо.

Ну то есть вы можете сделать все придерживаясь принципов REST. Главное не путать http и rest и не ограничивать себя мыслью что ресурсы это отображение табличек в базе.

При этом нужно учитывать что методов или урлов будет несколько сотен.

А какая разница? У вас так и так будет какой-то роутер.

Answer 3

[Andrey Vorobyov]

Фронтенд на python? ... жаба гадюку

Answer 4

[Алексей Черемисин]

REST предпочтительнее, на мой взгляд, так как меньше жрет ресурсов, легче отлаживать, проще использовать. Ну а данные конечно же гоняйте в json.

Comments

[aol-nnov]

> REST ... меньше жрет ресурсов
эм?... можно чем-то это экспертное мнение подкрепить? :)

[Алексей Черемисин]

aol-nnov: как минимум тем, что нам сначала нужно принять json, из него взять метод, его параметры, uid вызова, отмапировать метод на метод в коде, вызвать его с передачей параметров, сформировать ответ. В рест же метод и параметры передаются стандартным способом через гет или пост, а ответ - json в произвольной форме. Со стороны js для вызова нужно тоже немного постараться, простой json еще нужно обернуть в метод с параметрами и uid.

[Алексей Черемисин]

aol-nnov: другими словами, если использовать rest + json, заморачиваться ни с чем не нужно, а с json-rpc немного поплясать. А результат будет аналогичный. Да и отлаживаться с rest гораздо легче. Ну на напоследок, давайте посмотрим например на всевозможные api от гугла, яндекса, мордокниги и т.д. Кто из них использует json-rpc?

[aol-nnov]

Алексей Черемисин: это всё словоблудство. сериализация/десериализация будет при обоих способах взаимодействия, а уж "давайте посмотрим например на всевозможные api от гугла," - это вообще не по теме моего вопроса.
я к чему веду-то? вы, сударь, фигню написали. вот. :)

Answer 5

[Петр]

Зависит от задачи.
Плюсы Json-RPC:
1. Единая точка входа
2. За один запрос можно выполнить несколько действий.

Comments

[Сергей Протько]

1. С каких пор единая точка входа это плюс?
2. REST не налагает таких ограничений, а стало быть это не плюс по сравнению с rest.

[Петр]

Сергей Протько: 1. Чтобы не плодить в коде клиента множество различных url. 2. Если действие прописано в URL, то как выполнить несколько разнообразных действий?

[Сергей Протько]

Петр: действие не прописывается в url, в url описываются ресурсы. В этом кардинальная разница в понимании того что есть rest а чем он не является.

Вы можете сделать отдельный ресурс, который описывает коллекцию действий над какой-то сущностью. И вы просто создаете кучу ресурсов.

Ну то есть никаких ограничений.

А что до "плодить урлы" - тогда вы начинаете запихивать в респонсы какие-то идентификаторы "что пришло". Структуры данных и т.д. уже усложняются. Ну то есть шило на мыло.

json rpc (когда все действия исключительно через POST, даже на выборку) сложнее масштабировать. Вот и все.