Support Headers, Query Params and Request Body in GET handler of the echo router.

[hop-along-polly]

Context

A Manifest is a JSON object that maps an HTTP Request to a single HTTP Response OR series of HTTP Responses. When a customers test-suite starts up a Manifest should be uploaded to the /manifests endpoint of the AlwaysON server. This manifest maps all of the Requests the test-suite will send and what responses the AlwaysON Echo API should respond with when it receives that request.

Currently a customer can only specify the Method and URL for a Request which means there is an incredibly likely change the same request needs to be configured with a myriad of different responses. Here is what a manifest might look like as of right now.

[
  {
    "request": {
      "method": "GET",
      "url": "https://testerozza.io/health"
    },
    "responses": [{
      "status_code": 200,
      "body": { "status": "healthy" }
    }]
  }
]

Feature Request

[
  {
    "request": {
      "method": "GET",
      "url": "https://testerozza.io/health",
      "headers": [
         { "key": "content-type", "value": "application/json"  }
      ],
     "body": {},
     "query_params": [
         { "key": "sort", "value": "-createdAt"  }
     ]
    },
    "responses": [{
      "status_code": 200,
      "body": { "status": "healthy" }
    }]
  }
]

AlwaysON needs to support the following fields for a Request in a Manifest headers, query_params, and body. After this change a customer should be able to upload a manifest that looks like this

Considerations

Since Query Params are part of the URL we may drop that field and just let them be part of the URL. The only argument I have against that is some libraries take an object or dict as the query string params and it would be really nice not having to force customers into building that URL. All that being said for an MVP making the customer build the query params into the URL is probably fine.

Out of Scope

I've decided that using file blobs, application/form-data and other more complex Mime types will be a premium feature so there is only a need to support JSON for the body at this point.