httq
Middleware for bridging HTTP and AMQP
Installation
npm install httq
Prequisits
- RabbitMQ
- Familiarity with Rascal
Usage
Step 1 - Plug httq into an express app
var httq = var async = var rascal = var express = var bodyParser = var config = var rascalConfig = rascal rascal
Step 2 - Configure httq and rascal
Step 3 - Start the app and send it an HTTP request
$ node server.js &$ curl -H "Content-Type: application/json" -X POST -d '' http://localhost:3000/api/library/v1/books/978-0132350884/loans
Step 4 - Check your broker for the message.
It should look something like this:
Middleware
httq middleware needs to be initialised for each route in your express application, by passing httq.init with a broker, configuration, ctx (optional), and callback. The init method will build a chain of middleware in the order defined by the sequence attribute. If you need to pass paramters to a specific middleware then specifiy it in the warez block.
Each middleware in the chain should export a single function that expects the config, context and callback. It should return the a function with typical express middleware signature. If you want a middleware to appear twice just relist it in the sequence. If you want the two instances to have different parameters, give it a unique name and specify the 'type' parameter.
module { // ... }
Provided Middleware
requestToTemplateVars
Extracts variables from the request and stores them in req.httq.templateVars, e.g.
templateVars: method: "POST" url: "/api/library/v1/books/978-0132350884/loans" params: isbn: "978-0132350884" headers: user-agent: "curl/7.30.0" host: "localhost:3000" accept: "*/*" content-type: "application/json" content-length: "20" query: These are typically usd when generating the routing key and message published to your AMQP broker #### requestToRoutingKeyGenerates a routing key from the request by passing the templateVars through a hogan template The routing key is stored in reqhttqmessageroutingKey```json{ "requestToRoutingKey": { "options": { "template": "library.v2.books.loans.{{request.method}}" } }}
You can map the request method to something more meaningful
"requestToRoutingKey": "options": "template": "library.v2.books.loans.{{request.method}}" "method": "mapping": "POST": "created"
requestPathToRoutingKey
Generates a routing key from the request by replacing slashes with full stops. The routing key is stored in req.httq.message.routingKey. No parameters are required but you may optionall include the request method.
requestToMessage
Generates AMQP message headers and content from the request. This is stored in req.httq.message.headers and req.httq.message.content. You can see an example of the generated message in step 4.
requestToMessageContent
Generates AMQP message content from the request. A json document reprsenting the full request (url, params, headers, query parameters and body) is stored in req.httq.message.content
requestToSchemaUrl
Generates a schema url from the request by passing the templateVars through a hogan template. The routing key is stored in req.httq.message.schema
httpSourcedJsonValidator
Validates the message against a JSON schema downloaded using http. The validator uses tv4 and tv4-formats. The schema url must be set it req.httq.message.schema and will be downloaded and cached (along with any referenced schemas) in during the request flow. If a schema cannot be downloaded the middleware responds with 500. If validation succeeds the message will be decorated with an httq header giving the uri of the schema that the message was validated against. If validation fails, httq will respond with 400 'Bad Request' and a json document describing the errors, e.g.
s3SourcedJsonValidator
Validates the message against a JSON schema from S3. The validator uses tv4 and tv4-formats. The schema url must be set it req.httq.message.schema and will be downloaded and cached (along with any referenced schemas) in during the request flow. If a schema cannot be downloaded the middleware responds with 500. If validation succeeds the message will be decorated with an httq header giving the uri of the schema that the message was validated against. If validation fails, httq will respond with 400 'Bad Request' and a json document describing the errors as specified above.
The s3SourcedJsonValidator requires the following configuration
filesystemSourcedJsonValidator
Validates the message against a JSON schema from the file system. The validator uses tv4 and tv4-formats. The schema url must be set it req.httq.message.schema and will be loaded and cached (along with any referenced schemas) in during the request flow. If a schema cannot be read the middleware responds with 500. If validation succeeds the message will be decorated with an httq header giving the uri of the schema that the message was validated against. If validation fails, httq will respond with 400 'Bad Request' and a json document describing the errors as specified above.
fireAndForget
Publishes the AMQP message to a Rascal publication using the routing key defined in the context. If successful the middleware will return 202 "Accepted" and a transaction id corresponding to the message id
Custom Middlware
You can override the httq middleware or add your own by initialising the ctx "warez" attribute, e.g.
var customFireAndForget = var extraMiddleware = httq