Я создаю микросервис, отвечающий за выполнение всех уведомлений (например, электронной почты, смс), которые запускаются другими интерфейсами и микросервисами. Это делается для централизации всей логики и обработки уведомлений. Действие уведомления инициируется путем вызова его URL-адреса остальной веб-службы.Дилемма дизайна по уведомлениям Microservice с использованием REST
Теперь это моя дилемма. Должен ли я составлять единый URL-адрес для каждого типа запроса или одного URL-адреса для всех?
например.
ОПЦИЯ1
@Path("{sourceId}/registationEmail")
@Path("{sourceId}/forgotPasswordEmail")
@Path("{sourceId}/productionTicketEmail")
@Path("{sourceId}/registationSms")
@Path("{sourceId}/forgotPasswordSms")
@Path("{sourceId}/productionTicketSms")
или
ВАРИАНТ 2
@Path("{sourceId}/email")
@Path("{sourceId}/sms")
Проблема здесь мы используем @BeanParam в качестве входных данных, так что каждый тип уведомления будет иметь другой набор входные значения. Это основная проблема, которую мы решили перейти на вариант 2, или есть способ обойти это в настройке REST?
Проблема заключается в том, что логика обработки конструирования содержимого электронной почты должна выполняться с помощью этой веб-службы Уведомления, поэтому мы не можем отправить построенное тело сообщения этой службе в качестве входных данных, только необходимые параметры для создания тела сообщения –
так в чем же проблема? вместо того, чтобы иметь свойство тела, у вас будет несколько меньших (?), разные, с разными значениями для каждого типа email/sms; поскольку все электронные письма требуют аналогичных параметров (типы/имена, а не фактические значения), это может обслуживаться через одну конечную точку с общей моделью –
. Проблема заключается в том, что для каждого типа электронной почты требуется другой набор входных данных. Таким образом, вы можете повторно использовать один и тот же вход BeanParam. –