One unique feature of Prism is that it in addition to sending requests to HTTP Endpoints, it can also serialize the HttpRequest as JSON and post them to Redis Queues/Channels. A non-HTTP service (let's call them Redis Services) subscribed to the channel will be able to pick them up and process it further. The non-HTTP service is also expected to post an HttpResponse back so that Prism can respond to the client.
Let's see how this works.
The example above defines two Redis Http Services (userservice and messageservice) bound to the route POST /users. The type of the service needs to be specified as
type: "redis", as in the example above. When Prism receives a request at '/users', it serializes the request as JSON into a RedisHttpRequest and posts it to the 'serviceChannel' specified for each service. In the example above, the channels are 'userserviceinput' and 'messagingserviceinput'.
Each request comes with a responseChannel, which is the channel to which the service should post the response back. Prism will be subscribed to those channels.
The 'id' property of the response should be the same as the id received in the request; this is how Prism identifies the corresponding request. The 'service' property should be the name of the service.
Let's look at an example (for messagingservice):
Redis Http Services benefit from all the Prism features mentioned in the docs, such as Rate Limiting, Authentication, Circuit Breakers, etc. In fact, a single route can have a combination of regular Http Endpoints as well as Redis Http Services - as in this example below.
We have no idea if you'll need this, but go crazy. It's a fully supported feature.