Fronting RabbitMQ Services with REST

• speed
• to support multiple programming languages
• a platform for legacy services
• to support a large number of services
• to support mixed payload formats
• to support mixed protocols
• to provide fault isolation
• to support logging and usage reports

ETrade Needed

ETrade Solution

• ​realized REST can be applied to non-HTTP protocols
• most services are AMQP-based for performance and fault tolerance reasons
• legacy services still used request-response
• bridge the two worlds

Their "aha" Moment

• ​introduced an API gateway
• implemented in node.js and Express
• wanted non-blocking I/O
• easily could have been Ratpack or vert.x
• provides protocol conversion
• provides payload conversion
• provides service routing
• aggregates parallel service calls
• avoids boilerplate code
• good at REST, leaves business logic to the services

API Gateway

• ​REST uses URIs to route to services
• AMQP uses exchanges and routing keys to route to services
• gateway maps URIs to routing keys
• GET /account/1234 becomes the key GET/account/{id}
• the mapping is simple and easily understood
• all messages get sent to the same exchange and RabbitMQ handles the routing via the key
• RFC 6570 URI templates easily supported

Routing Technique

• ​HTTP headers have to be transformed into AMQP headers
• some headers are common but most are protocol specific
• AMQP has a "bucket" in its message structure for custom key-value pairs so HTTP headers can be preserved there
• gateway sets up a one-time listener for the response from the service
• response from the service is returned back to the caller
• newer streaming HTTP preferred but not always possible in older clients

Protocol Translation

• dead letter exchanges used to deal with messages that get rejected, exceed their TTL or when queue lengths are exceeded
• alternate exchanges used to deal with messages that cannot be routed
• not mentioned directly but the gateway must have timeouts  in place to avoid waiting for a reply forever 
• unclear how partial failures are dealt with -- only 4 of 5 aggregated services responded

Handling Failures

• REST clients preferred JSON
• AMQP services preferred XML
• Gateway handles the transformations between the two
• URI variables get transformed into tags in the XML
• caching possible if etag and if-matches constructs are used in the HTTP requests
• should be possible to use content-type meta-data to transform between different versions of payloads

Payload Transformation

• a service implementation and its exposed API is cleanly separated
• REST endpoints are easier for QA to test against
• gateway can emit reportable events to track API usage and failures
• using Level 2 of the Richardson model (no hyper-media)
• can virtualize services for different types of testing (replace a real service with a fake one, for example)
• can use Ratpack or Vert.x for a JVM solution

Observations

• Ratpack supports the Reactive APIs to simplify serializing the callbacks
• Java 8 Streams might be another option
• LMAX Distruptor might be another alternative
• If possible, use web client APIs that don't block waiting for an answer, such as web sockets
• having all services publish to a single exchange simplifies event producer code
• having exchange keys mimic REST URI is a "bleed through" of a protocol

Observations

• gateway needs to return HTTP status code in addition to failures
• does this imply that service payloads also provide HTTP status codes?
• again, might be more "bleed through"
• gateway provides a nice delineation between public APIs and "behind the firewall" private service APIs.  
• to work with the gateway, services will have to conform on a set of exchange patterns -- which is probably a good thing
• allows for efficient binary payloads behind the firewall

Observations

• unclear if a single gateway or multiple gateways exist
• a single gateway might become unweildy

Observations