Это то, что Мартин Фаулер назвал умными конечными точками и немыми трубами .
Что касается того, что лучше: нет явного "победителя", потому что они не являются взаимоисключающими.Они служат различным семантическим целям (хотя могут давать одни и те же результаты) и могут использоваться вместе в одном приложении.
Единственное, что вам нужно помнить, это то, что модель событий по своей сути асинхронна, и вы должны обращаться с ней таким образом.Конечно, вы можете придумать какое-то соглашение об уровне обслуживания, чтобы сообщения казались синхронными или создавали синхронные эффекты на интерфейсе, но все же.
Что касается плюсов и минусов, я могу дать вам несколько утверждений, которые могут помочь вам принять решениеКогда использовать какую технику:
- Связь - сравнивая модель, управляемую активными событиями, и простой API, вы можете сказать, что API обеспечивает более тесную связь, поскольку вы должны следовать некоторому предопределенному интерфейсу.В этом отношении сообщения не так строги, но при необходимости они могут быть
- Масштабирование - модель, управляемая событиями, масштабируется гораздо проще: создайте еще несколько рабочих, и все готово.Однако это отсутствие состояния может стать проблемой - вам может понадобиться один и тот же работник для обработки определенных событий, что может привести к довольно сложной архитектуре очередей
- Обработка ошибок - реализация обработки ошибок в REST API может бытьтак же просто, как выдать соответствующую ошибку и покончить с этим.Но что, если вам нужно повторить неудачный запрос к внешнему сервису?Это должно быть сделано на стороне API-интерфейса или на стороне клиента?Что делать, если вам нужен другой тип логики повторения для каждого запроса?Ваш API может стать слишком умным, что обычно плохо
- Блокировка против неблокирования - есть ли у вас план на случай непредвиденных обстоятельств, если ваша служба не соответствует ожидаемому SLA?Блокировка также может быть проблемой, но, по крайней мере, вы можете контролировать поток и контролировать процесс выполнения
- Отказоустойчивость - вы можете потерять ценные данные, если ваш API аварийно завершит работу во время выполнения.Очередь позволяет вам ждать, пока рабочие снова станут доступными
Это только основные моменты, этот список ни в коем случае не окончательный.Оба метода влекут за собой различные сложности в вашем приложении.Лучший совет здесь - использовать качественные высказывания (вроде тех, что указаны выше), здравый смысл и ПОЦЕЛУЙ, чтобы решить, что больше подходит для вашего случая (или, может быть, и того, и другого?).