Реализация REST с использованием таблиц JDBC - PullRequest
0 голосов
/ 28 сентября 2019

В настоящее время мы реализуем REST API с использованием spring-boot.Поскольку количество наших API растет, мы подумываем о решении для реализации API REST, использующем другой подход.

Подход такой, как показано ниже:

  • Предоставьте один сервис для получениявсе запросы HTTP.
  • У нас будут настроены URI в таблице базы данных для вызова следующего набора служб.Эти службы настроены на прослушивание определенных сообщений JMS.
  • Следующий набор служб будет получать сообщения JMS и обрабатывать данные.

Ниже приведены мои вопросы:

  • Будет ли приведенный выше подход по-прежнему представлять архитектуру REST?
  • Каковы недостатки вышеупомянутого подхода (мы знаем о задержке в сети) в чем-либо, кроме задержки в сети?
  • Чтомы упустим преимущества архитектуры REST.

Или мы можем просто сказать, что наш подход заключается в том, что архитектура REST сделана иначе?

1 Ответ

0 голосов
/ 28 сентября 2019

Вы делаете 2 основных выбора, каждый из которых может быть решен отдельно:

1) Наличие единой службы HTTP

2) Использование JMS в качестве связи между этой службой и базовыми микросервисами

Что касается # 1, если вы сделаете это, вы больше не сможете вызывать свои службы REST, поскольку весь смысл REST состоит в том, чтобы использовать HTTP-глаголы вместе с объектами вашего домена для предсказуемого набора конечных точек.GET on / objects / означает, что объект извлекается, POST on / objects означает, что создается новый объект и т. Д. Теперь, все в порядке, вы можете сделать это таким образом, и это может работать, хотя и будет "нестандартный ".

На самом деле, вы можете попробовать GraphQL https://www.howtographql.com/basics/1-graphql-is-the-better-rest/, поскольку он довольно близок к тому, что вы пытаетесь сделать.

В наши дни на самом деле либоREST или GraphQL, кажется, являются двумя популярными подходами.

Еще один способ сделать REST, если вы хотите просто предоставлять REST-сервисы для ваших доменных объектов без необходимости писать много кода, это Spring Data REST.: https://spring.io/projects/spring-data-rest и если вы уже знакомы с Spring, это должно быть довольно легко понять.

Для # 2 - ваш выбор связи между службой единого шлюза и базовыми службами.Требуется ли для большинства ваших вызовов синхронный ответ, например, пользовательский интерфейс, запрашивающий данные для отображения в браузере или телефоне?Если это так, JMS не очень хороший подход.JMS был бы хорошим подходом, если бы большинство ваших услуг были асинхронными - например, кто-то отправлял запрос на торговлю акциями.Пользовательский интерфейс должен знать, что запрос был отправлен, но на самом деле он будет обработан через некоторое время, а результат будет получен асинхронно.

Не зная о вашем приложении, я бы рекомендовал придерживаться HTTP междууслуги ради простоты, если нет веских причин для перехода на JMS.

...