Как правильно совметить REST API и JSON-RPC 2.0 в одном API?

Question

[kovert99]

Доброго времени, в ходе разработке REST API для веб-приложений, возникла мысль об использовании JSON-RPC 2.0 для выполнение всех операций, не имеющих отношения к прямому CRUD взаимодействию с ресурсами.

Например, с помощью JSON-RPC можно было бы реализовать следующие запросы:

• Аутентификация пользователя с последующим возвратом access_token
  
• Отправка письма на посту
  
• Взаимодействие со сторонними сервисами
  

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

Кто нибудь сталкивался с подобным извратом? Если да - то какие тут могут возникнуть подводные камни с точки зрения разработки клиентских приложений?

Comments

[Антон Швец]

Сталкивался, и при первой же возможности выпиливаю куски RPC и заменяю рестом, там где это возможно.

Answer 1

[Иван Шумов]

Сталкивался, даже когда-то делал. Только за такое руки отрывать надо по тому что это не REST. Любой RPC изначально предназначался для асинхронных операций тогда когда REST является синхронным протоколом

Comments

[kovert99]

Я понимаю, но для JSON RPC вообще нет надобности соблюдать REST. Речь ведь идет о том, чтобы как-то разграничить все взаимодействие с сервером на REST и JSON-RPC. То есть, оба API будут находится на одном сервере и использовать общие базы данных, но будут отделены друг от друга. Например, можно будет реализовать их на разных субдоменах и вести для каждого из них разное версионирование.

[Иван Шумов]

kovert99, вы сказали в одном API. Делать разные API для разной работы можно, конечно