Learn How Solace’s New and Improved REST Delivery Points Work | MFH February 2022

[Deleted User]

We had a couple of really great features come out in Solace PubSub+ Broker v9.11 related to REST delivery points (RDPs) that expand support for REST APIs, so that’s the topic of this month’s Feature Highlight Training.

Sign up to Solace Academy to get access to our February 2022 Monthly Feature Highlight Training and read on to learn about the features you’ll be learning to implement:

Custom HTTP Headers for REST Delivery Points

REST Delivery Points (RDPs) let clients more easily connect REST API's with their event broker without having to create a consumer to consume events and pass them on.

One of the issues that has arisen with this implementation is that not all REST API's are built the same. Some require “bearer” token authorization while others get by with “basic.” Some force REST API calls to include certain metadata in specific HTTP headers, and before version 9.11 custom HTTP headers weren't even possible.

With v9.11 you can now add custom HTTP headers to outgoing RDP messages, which vastly opens the possibilities of which REST APIs can be used by RDPs. Now when creating or modifying a queue binding for an RDP there is a section for request headers where you can specify static values and even use substitution expressions to pull values from the event for the HTTP header values.

Substitution Expressions for REST Delivery Points

One of the cool features a good REST API framework has is the ability to have dynamic endpoints. For example, you can have an endpoint dogs/{breed} where {breed} is the name of a breed of dog.

Before Event Broker v9.11 this would result in a lot of legwork when it came to using RDPs to publish events to a REST API. In the above example if you had events for a pet sitting service coming in with a topic of pet/check-in/dog/{breed} you would need to create a separate queue and queue binding to send to multiple REST API endpoints. Your results would look something like this.

• 1 queue and 1 queue binding for dogs/poodle
• 1 queue and 1 queue binding for dogs/german-shepherd
• 1 queue and 1 queue binding for dogs/pitbull

This means not only would you have to create 3 queues and 3 queue bindings but you would need to know all the different breeds you could receive, and create a queue and queue binding for each of them!

Event Broker now allows you to use substitution expressions when defining the post request target for a queue binding so you can define values from the event in the URL for the REST endpoint.

So for our above example, if we know that the topics coming in are pet/check-in/dog/{breed} we can create a single queue binding and define the post request target as dogs/${topic(4)}. This will take the fourth value in the topic and place it in that space!

Enums in PubSub+ Event Portal

In a good event-driven system, topics for events are well defined, but that doesn't mean they're necessarily static. For example, let's say you have a pet sitting company that just had a cat check in to their location. This could have a topic address like pet/check-in/{species}/{breed}. This is a well-defined topic, but it's far from being static because there are many different species of animal and many different breeds of each species.

In the past this has made designing topic addresses in PubSub+ Event Portal a bit cumbersome. While you had the ability to add a variable to your topic address (like species in the topic address above) it assumed that a species could potentially be any type of animal on the planet, even though the pet sitting company may only pet sit dogs, cats and birds. PubSub+ Event Portal has the ability to define an enumeration (or “enum”) for a variable used in a topic address. In the example above we are able to define in Event Portal the fact that the only values available for species are cat, dog and bird.

Sound interesting? Sign up for this month’s Feature Highlight Training now!