Дилемма дизайна по уведомлениям Microservice с использованием REST

Я создаю микросервис, отвечающий за выполнение всех уведомлений (например, электронной почты, смс), которые запускаются другими интерфейсами и микросервисами. Это делается для централизации всей логики и обработки уведомлений. Действие уведомления инициируется путем вызова его 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?

источник

2016-07-27 Davoin Showerhandles

Глядя на Richardson Maturity Model level 1, я бы сказал, что у вас действительно есть не более 2 ресурсов (ака опция 2), и оба могут иметь свойство типа. Конечно, у них будет другой набор входных значений, но все эти типы электронной почты должны иметь одинаковые свойства, правильно (From, To, Subject, Body и т. Д.)? Нет смысла иметь отдельную конечную точку, если она будет выглядеть и вести себя так же, как 2 других.

источник

2016-07-27 05:55:44

Проблема заключается в том, что логика обработки конструирования содержимого электронной почты должна выполняться с помощью этой веб-службы Уведомления, поэтому мы не можем отправить построенное тело сообщения этой службе в качестве входных данных, только необходимые параметры для создания тела сообщения –

так в чем же проблема? вместо того, чтобы иметь свойство тела, у вас будет несколько меньших (?), разные, с разными значениями для каждого типа email/sms; поскольку все электронные письма требуют аналогичных параметров (типы/имена, а не фактические значения), это может обслуживаться через одну конечную точку с общей моделью –

. Проблема заключается в том, что для каждого типа электронной почты требуется другой набор входных данных. Таким образом, вы можете повторно использовать один и тот же вход BeanParam. –

Я хотел бы пойти на вариант 2:

@Path("{sourceId}/email") 
@Path("{sourceId}/sms")

Он выглядит намного лучше, чем другой вариант.

Я не знаю, что ваш полный URI выглядит, но я бы что-то вроде /sources/{sourceId}/email или /sources/{sourceId}/notification/email.

И ваш запрос может быть как:

POST /sources/{sourceId}/email HTTP/1.1 
Host: example.com 
Content-Type: application/json 

{ 
    "to": "[email protected]", 
    "subject": "Question 38602123", 
    "body": "Lorem ipsum dolor sit amet, consectetur adipiscing elit." 
}

Вы не описываем детали о том, что ваш вход выглядит. Никаких сведений о зависимостях, которые вы используете. Поэтому трудно догадаться и дать окончательный ответ.

Вы упомянули @BeanParam, поэтому я предполагаю, что вы используете JAX-RS и одну из своих реализаций, таких как Jersey. Если вы используете JSON или XML для представления своих ресурсов, очень вероятно, что вы используете Джексона.

Таким образом, для обработки разных входов вы можете использовать наследование и полиморфическую десерилизацию Джексона. Есть несколько аннотаций, таких как @JsonTypeInfo и @JsonSubTypes, которые сделают трюк.

источник

2016-07-27 08:25:32

Все шаблоны электронной почты должны управляться веб-службой уведомлений, поэтому отправка отформатированного сообщения в службу не может быть выполнена. У каждого типа электронной почты также есть другой набор входных данных, поэтому использование одного класса @BeanParam в конечном итоге будет иметь множество атрибутов для обработки всех данных, необходимых для каждого уведомления. –

@DavoinShowerhandles Почему бы вам не добавить пример ваш вопрос? –

Дилемма дизайна по уведомлениям Microservice с использованием REST

ответ

Смежные вопросы