Closed andrewkroh closed 3 years ago
Since this is meant to fake an HTTP Server, it should be able to handle a serie of requests. Maybe having some sort of configuration file to define how to behave and what to return to a particular call could be nice.
I was thinking of something on the lines:
// A list of match rule definitions.
// It will match by the combination of method, path, query, and request_headers.
// If no method is defined, any will match, if no query is defined, any will match, etc.
// They will match in order, so more specific rules must go on top.
[
{
"method": "post",
"path":"/foo/bar", // accepts a regexp
"query": {}, // accepts a regexp in the values, the values must not be URL encoded.
"request_headers": {}, // they can accept regexp in the values.
"response_headers": {},
"tls": {
"cert": ""
// ...
},
"body": [ // If more than 1 body is defined,
// they will be returned in serie, first time the rule matches, will return body.0, second, body.1, etc.
"{
// Not sure how text/template would work here other that functions,
// where would we get the values from? maybe from the request?
}"
]
},
// ...
]
When it comes to pagination, I think with this the users can define how it should behave and fake pagination as needed.
Add an "output" that hosts the log messages via a REST API. The format of the returned document could be configurable via a Go text/template
Things that should be configurable: