Estou criando um serviço que enviará notificações para muitos outros serviços. Ele tem alguns tipos diferentes de notificação com os quais cada consumidor pode se importar, mas provavelmente não se importará com todos eles.
Em vez de exigir muitos terminais diferentes, estou pensando em criar um único terminal que tenha um parâmetro notificationType . Os consumidores das notificações podem descartar os tipos com os quais não se importam e a integração de outros serviços com o serviço de notificação é mais fácil.
Este é um padrão (ou anti-padrão)? Como isso é chamado? Parece que nos dias dos esquemas XML isso era uma coisa mais comum do que com o JSON (antes do meu tempo, mas eu sei de sistemas legados que fazem isso). Isso também me lembra um proxy reverso, mas parece diferente. Eu suponho que é desaprovado agora, mas não sei como procurar por discussões sobre isso.
Instead of requiring many different endpoints, I am thinking of making a single endpoint that has a notificationType parameter.
Para resumir, você está decidindo
http://example.com/notifications/<notificationType>
e
http://example.com/notifications/?notificationType=<notificationType>
certo?
Bem, o primeiro segue mais estritamente o REST. E o segundo torna mais fácil para você se inscrever em vários tipos de notificação de uma só vez. Mas de qualquer forma eles são muito semelhantes entre si e o uso de cada um deles depende do design do seu sistema. Se os seus tipos de notificação são muito granulares, há poucos deles, vá com o primeiro. Se houver muitos deles - escolha o segundo.
Parece que você está passando a mala para o próximo serviço. Por que não criar eventos diferentes para diferentes casos de uso e só fazer com que os consumidores se inscrevam nos eventos em que estão interessados. Concordo com o Caleb. Olhe para um padrão de Barramento de Eventos, desde que sejam micro-serviços na mesma máquina