4

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.

Vladislav Rastrusny
  • 1,844
  • 12
  • 14
Steve Ellis
  • 157
  • 2
  • 5
    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 09 '16 at 21:46
  • 7
    Another term that is often used for this is ["Message Broker"](http://www.enterpriseintegrationpatterns.com/patterns/messaging/MessageBroker.html) – Caleb Dec 10 '16 at 10:33
  • 7
    Also, you might want to look up ["Enterprise Service Bus"](http://soapatterns.org/compound_patterns/enterprise_service_bus) – Caleb Dec 10 '16 at 10:35

4 Answers4

0

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.

RubyPanther
  • 69
  • 4
0

A bit late, but anyways.

You already answered yourself. The integration pattern or strategy you describe sounds like Pub/Sub

a service that will push notifications to many other services

Commonly known as Publisher. It sends messages through a message broker. Messages can be broadcasted through a single topic/queue or many.

Consumers of the notifications can discard types they don't care about

Commonly known as Subscriber. They subscribe to topics/queues where messages are sent. If there's only one topic/queue, then they have to filter incoming messages somehow.

I am thinking of making a single endpoint that has a notificationType parameter

This is also known as Message Broker.

MessageBrokers, Publishers, Subscribers, Queues, etc are components of integration patterns. They can be combined in different ways.

The protocol doesn't need to be HTTP either. There're products supporting Pub/Sub that rely on message-transfer-specific protocols. For example, your Email uses one of them (SMTP).

Laiv
  • 14,283
  • 1
  • 31
  • 69
-1

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 

http://example.com/notifications/<notificationType>

and 

http://example.com/notifications/?notificationType=<notificationType>

right?

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.

Vladislav Rastrusny
  • 1,844
  • 12
  • 14
-1

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

th3monk3y
  • 1
  • 2