I am building a service that will push notifications to many other services. It has a couple of different notification types that each consumer may care about, but likely will not care about all of them.

Instead of requiring many different endpoints, I am thinking of making a single endpoint that has a notificationType parameter. Consumers of the notifications can discard types they don't care about, and integrating other services with the notification service is easier.

Is this a pattern(or anti-pattern)? What is it called? Seems like in the days of XML schemas this was a more common thing than it is with JSON(before my time, but I know of legacy systems that do this). It also reminds me of a reverse proxy, but seems different. I assume it is frowned on now, but don't know how to even search for discussions about it.

  • 4
    It's called "an endpoint that routes requests," or "a service that pushes notifications." Call it a "dispatcher" if you like. Other possible names: "router" and "hub." – Robert Harvey Dec 9 '16 at 21:46
  • 5
    Another term that is often used for this is "Message Broker" – Caleb Dec 10 '16 at 10:33
  • 5
    Also, you might want to look up "Enterprise Service Bus" – Caleb Dec 10 '16 at 10:35

As long as you're putting the type into the data and not baking it into the URL, then using the type instead of knowledge about endpoints is considered a Best Practice and is an important part of HATEOAS.

https://martinfowler.com/articles/richardsonMaturityModel.html is the best resource I know for explaining this.


Instead of requiring many different endpoints, I am thinking of making a single endpoint that has a notificationType parameter.

Just to summarize, you are deciding on





Well, the first one more strictly follows REST. And the second one makes it easier for you to subscribe to several notification types at once. But anyway they are very similar to each other and the use of each one depends on the design of your system. If your notification types are very granular, there are few of them, go with the first. If there are so many of them - choose second one.

  • What a URL looks like has zero to do with how RESTful the service is. – RubberDuck Dec 10 '18 at 11:07

It sounds to me like you are passing the bag to the next service. Why not raise different events for different use cases, and only have the consumers subscribe to the events they are interested in. I agree with Caleb. Look into an Event Bus pattern provided these are micro-services on the same machine

protected by gnat Jan 3 at 15:16

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.