friendsofgo/killgrave

Simple way to generate mock servers written in Go

killgrave's Issues

Improve the way to get the Version

Context

Today if you run Killgrave with a compiled version and you use the flag version you will get the last version that you have installed on your system. But if you want to compile Killgrave by your own or using go get command you will get dev.

This is happens because we are using the ldflags to configure the version when we build the realease version.

Proposed implementation

We need a easy way to store the version of the application and getting when the user use the flag version, although the version was compiled by the own user.

Proxy server feature

Context

One of the most requested features by our users is to implement a "proxy server" feature
(reasons below).

On the one hand, as the mock server is something you need to build up (provide) as you develop your API, sometimes there are some endpoints that are not already defined on the mock server configuration, so you might want to let the mock do a request to the "real" implementation when that happens.

OTOH, you might even want to have a "flag" that allows you to switch on-off the mock server.

Proposed implementation

Both situations can be solved by providing a configuration section named proxy_server with two attributes.

• The first one named mode (or similar) with the following choices:

  • all (all the requests will be redirected)
  • missing (only the missing requests will be redirected)
  • none -or off (no proxy, default value).

• The second one named base_url (or similar) to configure the origin of the "real" implementation.

For the proxy's implementation itself, there are many examples over internet about how to implement a proxy server with Go. Ideally, we won't want to add new third-party dependencies.

Any suggestion about that will be welcome.

Remove pkg/errors library

Since go1.13 version the library pkg/errors is depecrated in favor to errors on 1.13. IMHO I think that we don't need the extra library to handle the errors of our application, so I think that can be change all errors uses for new errors packages, using sentinels or wrapping it if it's necessary.

Start to use testify

Modify the test to start to use https://github.com/stretchr/testify instead of the native Go tests

schemaFile with array producing false positives

Trying to mock some ElasticSearch requests containing arrays, many of them with mixed type:

  "sort": [
    {
      "date": "desc"
    },
    "_score"
  ],
  "query": {   }

With a schemaFile like this or similar variations:

{
  "type": "object",
  "properties": {
    "sort": {
      "type": "array",
      "items": [
        {
          "type": "object",
          "properties": {
            "date": {
              "const": "desc"
            }
          }
        }
      ]
    }
  },
  "required": [
    "sort"
  ]
}

Any simple request like:

  "sort": [
    {
      "date": "desc"
    }
  ]

or changing to dateINVALID": "desc" they are always a match, array contents don't make a difference at all
https://json-schema.org/understanding-json-schema/reference/array#items

Same with prefixItems https://json-schema.org/understanding-json-schema/reference/array#tupleValidation

How can we use a schemaFile to filter by array contents?

A `correct_request_schema` fails on Windows

When executing tests on Windows the TestMatcherBySchema/correct_request_schema test fails. I'm not sure what the behaviour should be though. However if someone can tell me that the currently expected behaviour is, I will happily open a pull request to fix it.

$ go test -v ./...
?       github.com/friendsofgo/killgrave/cmd/killgrave  [no test files]
=== RUN   TestNewConfig
=== RUN   TestNewConfig/empty_config_file
=== RUN   TestNewConfig/valid_config_file
=== RUN   TestNewConfig/file_not_found
=== RUN   TestNewConfig/wrong_yaml_file
--- PASS: TestNewConfig (0.00s)
    --- PASS: TestNewConfig/empty_config_file (0.00s)
    --- PASS: TestNewConfig/valid_config_file (0.00s)
    --- PASS: TestNewConfig/file_not_found (0.00s)
    --- PASS: TestNewConfig/wrong_yaml_file (0.00s)
=== RUN   TestProxyModeParseString
=== RUN   TestProxyModeParseString/valid_mode
=== RUN   TestProxyModeParseString/unknown_mode
--- PASS: TestProxyModeParseString (0.00s)
    --- PASS: TestProxyModeParseString/valid_mode (0.00s)
    --- PASS: TestProxyModeParseString/unknown_mode (0.00s)
=== RUN   TestProxyModeUnmarshal
=== RUN   TestProxyModeUnmarshal/valid_mode_none
=== RUN   TestProxyModeUnmarshal/empty_mode
=== RUN   TestProxyModeUnmarshal/invalid_mode
=== RUN   TestProxyModeUnmarshal/error_input
=== RUN   TestProxyModeUnmarshal/valid_mode_all
=== RUN   TestProxyModeUnmarshal/valid_mode_missing
--- PASS: TestProxyModeUnmarshal (0.00s)
    --- PASS: TestProxyModeUnmarshal/valid_mode_none (0.00s)
    --- PASS: TestProxyModeUnmarshal/empty_mode (0.00s)
    --- PASS: TestProxyModeUnmarshal/invalid_mode (0.00s)
    --- PASS: TestProxyModeUnmarshal/error_input (0.00s)
    --- PASS: TestProxyModeUnmarshal/valid_mode_all (0.00s)
    --- PASS: TestProxyModeUnmarshal/valid_mode_missing (0.00s)
=== RUN   TestProxyMode_String
=== RUN   TestProxyMode_String/ProxyNone_must_be_return_none_string
=== RUN   TestProxyMode_String/ProxyNone_must_be_return_missing_string
=== RUN   TestProxyMode_String/ProxyNone_must_be_return_all_string
=== RUN   TestProxyMode_String/An_invalid_mode_must_return_none_string
--- PASS: TestProxyMode_String (0.00s)
    --- PASS: TestProxyMode_String/ProxyNone_must_be_return_none_string (0.00s)
    --- PASS: TestProxyMode_String/ProxyNone_must_be_return_missing_string (0.00s)
    --- PASS: TestProxyMode_String/ProxyNone_must_be_return_all_string (0.00s)
    --- PASS: TestProxyMode_String/An_invalid_mode_must_return_none_string (0.00s)
=== RUN   TestAttachWatcher
--- PASS: TestAttachWatcher (0.11s)
=== RUN   TestInitializeWatcher
=== RUN   TestInitializeWatcher/intialize_valid_watcher
=== RUN   TestInitializeWatcher/invalid_directory_to_watch
--- PASS: TestInitializeWatcher (0.00s)
    --- PASS: TestInitializeWatcher/intialize_valid_watcher (0.00s)
    --- PASS: TestInitializeWatcher/invalid_directory_to_watch (0.00s)
PASS
ok      github.com/friendsofgo/killgrave/internal       (cached)
=== RUN   TestImposterHandler
=== RUN   TestImposterHandler/valid_imposter_with_body
=== RUN   TestImposterHandler/valid_imposter_with_bodyFile
=== RUN   TestImposterHandler/valid_imposter_with_not_exists_bodyFile
--- PASS: TestImposterHandler (0.00s)
    --- PASS: TestImposterHandler/valid_imposter_with_body (0.00s)
    --- PASS: TestImposterHandler/valid_imposter_with_bodyFile (0.00s)
    --- PASS: TestImposterHandler/valid_imposter_with_not_exists_bodyFile (0.00s)
=== RUN   TestInvalidRequestWithSchema
=== RUN   TestInvalidRequestWithSchema/valid_request_no_schema
--- PASS: TestInvalidRequestWithSchema (0.00s)
    --- PASS: TestInvalidRequestWithSchema/valid_request_no_schema (0.00s)
=== RUN   TestNewProxy
=== RUN   TestNewProxy/valid_all
=== RUN   TestNewProxy/valid_mode_none
=== RUN   TestNewProxy/error_rawUrl
--- PASS: TestNewProxy (0.00s)
    --- PASS: TestNewProxy/valid_all (0.00s)
    --- PASS: TestNewProxy/valid_mode_none (0.00s)
    --- PASS: TestNewProxy/error_rawUrl (0.00s)
=== RUN   TestProxyHandler
--- PASS: TestProxyHandler (0.00s)
=== RUN   TestResponseDelayUnmarshal
=== RUN   TestResponseDelayUnmarshal/Invalid_type
=== RUN   TestResponseDelayUnmarshal/Valid_range_delay
=== RUN   TestResponseDelayUnmarshal/Range_delay_with_incorrect_delimiter
=== RUN   TestResponseDelayUnmarshal/Range_delay_with_extra_field
=== RUN   TestResponseDelayUnmarshal/Range_delay_where_second_point_is_before_first
=== RUN   TestResponseDelayUnmarshal/Valid_empty_delay
=== RUN   TestResponseDelayUnmarshal/Valid_fixed_delay
=== RUN   TestResponseDelayUnmarshal/Fixed_delay_without_unit_suffix
=== RUN   TestResponseDelayUnmarshal/Range_delay_where_second_point_invalid
--- PASS: TestResponseDelayUnmarshal (0.00s)
    --- PASS: TestResponseDelayUnmarshal/Invalid_type (0.00s)
    --- PASS: TestResponseDelayUnmarshal/Valid_range_delay (0.00s)
    --- PASS: TestResponseDelayUnmarshal/Range_delay_with_incorrect_delimiter (0.00s)
    --- PASS: TestResponseDelayUnmarshal/Range_delay_with_extra_field (0.00s)
    --- PASS: TestResponseDelayUnmarshal/Range_delay_where_second_point_is_before_first (0.00s)
    --- PASS: TestResponseDelayUnmarshal/Valid_empty_delay (0.00s)
    --- PASS: TestResponseDelayUnmarshal/Valid_fixed_delay (0.00s)
    --- PASS: TestResponseDelayUnmarshal/Fixed_delay_without_unit_suffix (0.00s)
    --- PASS: TestResponseDelayUnmarshal/Range_delay_where_second_point_invalid (0.00s)
=== RUN   TestResponseDelay
=== RUN   TestResponseDelay/Empty_delay
=== RUN   TestResponseDelay/Fixed_delay
=== RUN   TestResponseDelay/Range_delay
--- PASS: TestResponseDelay (0.00s)
    --- PASS: TestResponseDelay/Empty_delay (0.00s)
    --- PASS: TestResponseDelay/Fixed_delay (0.00s)
    --- PASS: TestResponseDelay/Range_delay (0.00s)
=== RUN   TestMatcherBySchema
=== RUN   TestMatcherBySchema/non-existing_schema_file
=== RUN   TestMatcherBySchema/empty_body_with_required_schema_file
=== RUN   TestMatcherBySchema/invalid_request_body
=== RUN   TestMatcherBySchema/correct_request_schema
    route_matchers_test.go:69: error while matching by request schema - expected: true, given: false
=== RUN   TestMatcherBySchema/imposter_without_request_schema
=== RUN   TestMatcherBySchema/malformatted_schema_file
=== RUN   TestMatcherBySchema/incorrect_request_schema
--- FAIL: TestMatcherBySchema (0.00s)
    --- PASS: TestMatcherBySchema/non-existing_schema_file (0.00s)
    --- PASS: TestMatcherBySchema/empty_body_with_required_schema_file (0.00s)
    --- PASS: TestMatcherBySchema/invalid_request_body (0.00s)
    --- FAIL: TestMatcherBySchema/correct_request_schema (0.00s)
    --- PASS: TestMatcherBySchema/imposter_without_request_schema (0.00s)
    --- PASS: TestMatcherBySchema/malformatted_schema_file (0.00s)
    --- PASS: TestMatcherBySchema/incorrect_request_schema (0.00s)
=== RUN   TestServer_Build
=== RUN   TestServer_Build/imposter_directory_not_found
=== RUN   TestServer_Build/malformatted_json
=== RUN   TestServer_Build/valid_imposter
--- PASS: TestServer_Build (0.00s)
    --- PASS: TestServer_Build/imposter_directory_not_found (0.00s)
    --- PASS: TestServer_Build/malformatted_json (0.00s)
    --- PASS: TestServer_Build/valid_imposter (0.00s)
=== RUN   TestBuildProxyMode
=== RUN   TestBuildProxyMode/ProxyAll
=== RUN   TestBuildProxyMode/ProxyMissing_Hit
=== RUN   TestBuildProxyMode/ProxyMissing_Proxied
=== RUN   TestBuildProxyMode/ProxyNone_Hit
=== RUN   TestBuildProxyMode/ProxyNone_Missing
--- PASS: TestBuildProxyMode (0.01s)
    --- PASS: TestBuildProxyMode/ProxyAll (0.00s)
    --- PASS: TestBuildProxyMode/ProxyMissing_Hit (0.00s)
    --- PASS: TestBuildProxyMode/ProxyMissing_Proxied (0.00s)
    --- PASS: TestBuildProxyMode/ProxyNone_Hit (0.00s)
    --- PASS: TestBuildProxyMode/ProxyNone_Missing (0.00s)
=== RUN   TestServer_AccessControl
--- PASS: TestServer_AccessControl (0.00s)
FAIL
FAIL    github.com/friendsofgo/killgrave/internal/server/http   0.171s
FAIL

Add shell completions for Killgrave CLI

Based on the most recent changes present on the branch v0.5.0, it seems Killgrave is introducing the use of Cobra as the library used to build and run the CLI commands.

Thus would be good to also add the shell (Bash, Zsh, fish, PowerShell) completions supported by the library.
More information here.

Allow XML schema validation on requests

Context

Killgrave was initially developed as a mock server focused on JSON HTTP APIs. However, as the responses configuration is highly flexible, it could be used to return responses of almost any type. That could allow Killgrave's users to use it also to mock XML HTTP APIs.

So, to provide those potential users a great experience, we also want to allow them configure some schema (XML) validations the same way as it's currently done for JSON requests.

Proposed implementation

The field (within imposter) to specify the file used for validation's definition can still being schemaFile (as it is currently for JSON validations).

The schema's file type (JSON vs XML) can be deduced from its extension (.json vs .xml) or a schemaType field can be eventually added.

Any suggestion about that will be welcome.

Structured logging

I think this project can hugely benefit from structured logging.
User should be able to see what request server handled and how (maybe why they haven't handled by supposed handler, what errors of validation happened. It can be difficult to inspect this manually).
So structured logging can help to deal with possibly huge logs that current project can generate.

We can use some dependency for this functionality such as:
https://github.com/sirupsen/logrus (very user friendly, also can be used instead of standard log)
https://github.com/uber-go/zap

Watcher mode not working

If watcher mode is true then server errors with only one instance allowed at a port

Problems using the Docker way

I have the next problem; you say to use this line to can run the Docker image
docker run -it --rm -p 3000:3000 -v $PWD/:/home -w /home friendsofgo/killgrave -h 0.0.0.0

but when y run this with this tree configuration

mymock/
-- imposters/
-- -- config.yml
-- -- swapi_people.imp.json
-- -- swapi_planets.imp.json

the image logs return the next message

Add a CircleCI job to push each new release to DockerHub

The Killgrave project uses CircleCI for build & test pipelines (see the configuration file here). Additionally, every release of Killgrave is present on Docker Hub. So, it'd be great to add a new CircleCI step to automatically push each new release to DockerHub.

Please, notice that this new job should be filtered in the same way as the release one.

Where is the Debug?

The docs says:

debugger:
   enabled: false
   address: localhost:3030

but i can't find any option to enable debugging via CLI

Refactor remove go core flag by cobra

Context

When Killgrave was born the idea was to create a simple mock server without multiple features, today, Killgrave is used by some companies in a large number of projects, for that reason Killgrave has been evolving and adding new features to make the tool more versatile.

Go flags is not very scalable and when you want to add more and more options could be a little inferno, for that reason we want to migrate all the flag handle of the cli to cobra one of more powerful tool inside of go community to handle and build very robust and scalables cli

Proposed implementation

Refactor the cli to start use cobra instead go flags, trying to apply SOLID architecture and cleaning the main.go

Add the possibility to run the mock server using HTTPS

We need to give the possibility to run the mock server using HTTPs, for that we need to add a new flag, for example, secure with a default certificate.

Also will be fine is we could add the option to add the own certificates for the users, via string and via file.

Problems with CORS in ajax petitions

In ajax petitions we have problems with CORS because the first petition is with OPTIONS and this petitions is not accepted in killgrave

File Watcher

This is a major feature for Killgrave, since now when you made any changes above the imposters file, you need to restar manually the server, this isn't be a problem if you already have a very stable mock server, but when you are creating and configurating your server this action is very frecuently.

For that with this PR I want to add this new feature, using the flag -watcher. The server would be reload with any changes above the imposters path that you choosed on starting.

Dockerization

Hello,

Just a suggestion:

It would be quite interesting to be able to run killgrave through Docker containers.

Thanks!

Bad English in the README

The README and other documentation files contain some bad English. It would be good to clean that up.

Record proxy server feature

(Straightly related with #33)

Context

A really very-well feature for Killgrave would be to be able to create "responses" (configuration) itself on-the-fly.

The idea is to let the user to configure only the imposter's request and then let Killgrave do the magic: fill the response section (within imposter) by going to the "real" implementation and getting the response.

Proposed implementation

That feature could be implemented on a two-steps development:

• Firstly, developing a module responsible of that magic (able to create configuration from an HTTP response).
• Secondly, allowing a new choice (record) for the proxy_server's mode configuration that would allow the user to enable that recording (just for the missing endpoints).

Brew installation (MacOS) does not work

Hi,

I tried to install Killgrave by using brew on a MacOs Monterey (i5) and it fails:

> brew install friendsofgo/tap/killgrave
Error: friendsofgo/tap/killgrave: Calling bottle :unneeded is disabled! There is no replacement.
Please report this issue to the friendsofgo/tap tap (not Homebrew/brew or Homebrew/core):
  /usr/local/Homebrew/Library/Taps/friendsofgo/homebrew-tap/Formula/killgrave.rb:10

So, would be good to do some research to understand why it's failing and how to fix it.

Thanks! 🙏🏻

Examples about dynamic responses

Hi guys
I was messing around your server mocker, and I was planning using it in one of our projects :)
I miss some examples, in specific, about how deal with dynamic responses based on regex endpoint or request schema. So, based in a value from request, I want to get that value and reflect it into the generated response.
If possible, could you provide some kind of example about that feature?
Thanks a lot in advance

Deploying killgrave in kubernetes ecosystem

Hi,
I'm trying to deploy killgrave in a pod on a kubernetes (Tanzu) plateform.
It deploys well with the following logs :
2022/10/18 13:42:53 imposter /etc/killgrave/imposters/..2022_10_18_13_42_52.903949163/gopher.imp.json loaded
2022/10/18 13:42:53 imposter /etc/killgrave/imposters/gopher.imp.json loaded
2022/10/18 13:42:53 The fake server is on tap now: 0.0.0.0:3000

But any http call from outside the container ends up in a time out.
Here's a call from a pod in the same namespace. My service maps the 300035 as a NodePort to the 3000 by the way :
bash-4.2$ curl -kv -H "Content-Type: text/json" mos-mock-ged.mos.svc.cluster.local:30035/gophers

• About to connect() to mos-mock-ged.mos.svc.cluster.local port 30035 (#0)
• Trying 100.28.252.169...
• Connection timed out
• Failed connect to mos-mock-ged.mos.svc.cluster.local:30035; Connection timed out
• Closing connection 0
  curl: (7) Failed connect to mos-mock-ged.mos.svc.cluster.local:30035; Connection timed out

Is there any subtelty in the configuration other than the host : 0.0.0.0 configuration I should try ?

I would like to see the incoming requests dump into stdout

I would like to have a way to configure, per imposter, if the incoming requests should be dumped to stdout or not.
Also would be nice to have a command line option to override all imposters dump configurations.

Add functionality for command execution/ run servers as cancellable services

This a really awesome project
I think it would be cool if the servers were able to run commands and then destroy the mocks
Similar to
https://github.com/jonhoo/minion and https://github.com/jonhoo/tsunami (except not for AWS)

I also have a go package for graceful shutdown of cancellable services (if adding this functionality is something that could be good for this project....

Is there any way to configure the value of the response?

Hi,

I would like to use this to mock an external API, my question is I can configure the response, for example:

POST Request with Body {"element_id": 2}
Response {"element_id": 2, "deleted":true}

Where value of element_id match in request and response.

How to mock a all sub paths?

Hi,

i've just found your project and really like the simplicity.
But i have trouble to mock responses for requests with unknown paths.
For example i want to mock the following requests:

- /api
- /api/23
- /something/...

and so on..
and i have tried a pattern like this

...
"endpoint": "/{*}"
...

But this would only match /api and not its sub-paths.
So is this currently possible? Something like a "catch-all" endpoint?

Thanks

Add support for most popular software management tools

I'd be nice to have support for:

• Aptitude (Debian/Ubuntu)
• RedHat
• Windows
• Homebrew (no tap)
• Etc

For any JSON schema I get 404 error

Even the schema that was provided in documentation also gives me the below error in terminal:

parse "file://D:\killgrave-master\killgrave-master/internal\server\http\test\testdata\imposters/schemas/create_gopher_request.json": invalid port ":\killgrave-master\killgrave-master" after host: error validating the json schema

In postman, I get 404-Not found.
I have attached files of imposter and schema with txt extension.
create_gopher.imp.txt
create_gopher_request.txt

Please help me out if I am missing something

Explore possible integrations with Bruno

Bruno (https://github.com/usebruno/bruno) is an alternative to Postman (and similar tools) that's gaining popularity, with its own language, also with support for defining test suites over the HTTP APIs.

So, could worth exploring if there's any kind of integration that would make sense, like any automatic translation from/to Bruno definitions, equivalent to OAPI/Swagger.

Allow setting different responses per request (repeats)

Context

A quite common feature on some of the mock servers of the market is the possibility to define a different response for each time an imposter is requested.

It basically will consists on returning the response A the first X times the imposter is requested, then returning the response B the next times and so on (as much flexible as possible).

Proposed implementation

As this is an issue tagged as just an idea, there's no implementation proposal.
Then, there's a single requirement: to keep Killgrave as simple as possible.

Example

Just as a proposal example,

It could be implemented by changing the response section (within imposter) from an object to an array of objects, adding to each of them a field times (or named similar) that would allow the user to set those different responses for each request.

However, it's entirely open, so feel free to write down a comment with your point-of-view and to start the discussion.

Config file paths suggestion

Hello,

Currently, if you want to use a config file, the paths on it are relative to the path where you are running the application. This does not make sense, because it implies the config should be changed depending on the way you run it.

IMHO, it would be better to specify the config file path relative to the path where you are running the application, but making the paths on the config file relative to the config path.

What do you think?

Thanks!

Support YAML for configuration and imposters definition

Hello,

As any valid JSON is also a valid YAML (by definition), this enhacement will provide both options to users without BCs, neither multiple developments.

Thanks!

docker compose documentation

Getting killgrave to work within docker compose, doing the volume mount, specifying the config file, isn't obvious. Can you add a docker compose example in the docs please? Thanks.

Allow run Killgrave with a config file

As improvement, it will be fine allow a optional config file with arguments to run your mock server like:

• port
• host
• imposters file
• CORS configuration

how to specify regex endpoints?

I'm trying to configure an endpoint that handles requests matching a regex.
Is there a sample configuration using this feature?

Project status

I start by telling you that your project is fantastic, I just wanted to know its status since there are some PR not included yet and the last commit is from September 2021.

Thanks so much

Mocking gRPC Servers

Context

Killgrave was born like an easy way to create mocks servers to HTTP APIs, so the philosophy of Killgrave was to make mocking easy and accessible to as many people as possible.

But now not only we have the HTTP APIs, there a lot of project that using gRPC to create theirs communications, so will be very interesting that find a way to do the Killgrave the way to mocking a gRPC server.

Proposed implementation

We will need to differentiate between an HTTP or gRPC server is calling, also we want to maintain the way to do the thing easy, so we need to find a solution that was easy to understand to everyone, so if it possible we want to continue using json to configure the imposters for the gRPC server.

Also we need that the config.yml could work for HTTP or gRPC

If you have any propose, please let us know.

Create imposters from Swagger responses schemas

Context

A lot of API that run on the world using Swagger to create a specification to document it. Is for that reason that we want to get the possibility to read the swagger files to create the imposters.

Proposed implementation

The idea is create a new flag called swagger-gen with the address of the swagger responses schema, we need to process those files to create all the necessary imposters on the directory that the user selected with the flag imposters.

We need create as many imposters for each endpoints as responses have, for example:

paths:
  /user/{userId}:
    get:
      summary: Returns a user by ID.
      parameters:
        - name: userId
          in: path
          required: true
          description: The ID of the user to return.
          schema:
            type: integer
            format: int64
            minimum: 1
      responses:
        '200':
          description: A user object.
          content:
            application/json:
              schema:
                type: object
                properties:
                  id:
                    type: integer
                    format: int64
                    example: 4
                  name:
                    type: string
                    example: Jessica Smith
        '400':
          description: The specified user ID is invalid (not a number).
        '404':
          description: A user with the specified ID was not found.
        default:
          description: Unexpected error

In this case we will need to create for the endpoint /user/{userId} with for imposters, one for 200 response, another for 400 and so on.

We need be compatible with OpenAPI 3 Specification and Open API 2 Specification we could do that letting to the user decide wich version want to use with two differents flags to select the path, swagger-gen and swagger3-gen

Interactive mode

Although it might be a bit out of the scope of this project, it could be interesting to enable an interactive mode in order to let the user to manually respond to some specific endpoints (applying same rules as regular imposters).

Since HTTP is a plaintext-based protocol, it shouldn't be harder than reading input from stdin and determining when then payload is finished (double /n or similar).

Thanks!!

Return bad request when you uses an invalid json schema

If you're declaring a json schema to validate to request body, when failed the mock could be more inteligent and return a 400 Bad Request instead to a 404 because the route is not found it.

Maybe we could add a param to handle this errors on the response... or return the error in a string in the response.

Query params

Además de indicar el path del endpoint, sería útil que se pudiera añadir query params.

Sugerencia: Según he visto en la documentación de Gorilla Mux (https://github.com/gorilla/mux#matching-routes), se pueden añadir query params al router de la siguiente manera:

r.Queries("key", "value")

Response headers

Estaría bien que fuera posible definir los headers de la response, tal y como ya se hace para la request.

The endpoint should work with final `/` or without it

If we have a imposter like this:

[
    {
        "request": {
            "method": "GET",
            "endpoint": "/api/people/1"
        },
        "response": {
            "status": 200,
            "headers": {
                "Content-Type": "application/json"
            },
            "bodyFile": "swapi_luke.json"
        }
    }
]

And will try to call to this endpoint on this way: http://localhost:3000/api/people/1/ the mock server will return a 404 because it's not matching with the path.

So the normal behaviour is that url ignoring if have a / or not and have the same behaviour

Improve the documentation

Context

Right now the tool Killgrave is using for differents companies and users, but the documentation on the repository is very poor with a very little examples. We need to improve that point to bring closer this amazing tool to more people.

Proposed implementation

The idea will be to create a doc/ directory, with an index on the main README.md listing all the features that Killgrave have.

So inside of doc/ folder we will create a pages for this features using markdown, giving a examples of how to use the tool in each case.

In this two issues, we have examples of how to use features that doesn't have any documentation yet:

• How to create dynamic responses
• How to use the regex on endpoints

If you are insteresing on participate in this task, let us know we could create a group on discord, slack or whatever to discuss the topic and organize the documentation.

Callback Service Call

When the mock server gets a request after a while sends a request to the given url. This feature might be useful for 3rd API service which works with send notifications. I prepared case:

    {
        "request": {
            "method": "GET",
            "endpoint": "/gophers/01D8EMQ185CA8PRGE20DKZTGSR"            
        },
        "callback": {
            "request": {
                "method": "GET",
                "endpoint": "http://localhost:8089/v1",
                "headers": {
                    "Content-Type": "application/json"
                },
                "body": "{\"test\": \"test\"}"
                    
            },
            "delay" : "5s:10s"
        },
        "response": {
            "status": 200,
            "headers": {
                "Content-Type": "application/json"
            },
            "body": "{\"data\":{\"type\":\"gophers\",\"id\":\"01D8EMQ185CA8PRGE20DKZTGSR\",\"attributes\":{\"name\":\"Zebediah\",\"color\":\"Purples\",\"age\":55}}}"
        }
    }
]

when request get by mock server after given delay, it will send request to "http://localhost:8089/v1""
As mentioned I prepared codes then it works.

Watcher option is not configured on the config.file

Context

All the options that the command line tool can do, the config file should be replicate also, but the watcher options is not parsed when the config is load.

Proposed implementation

Add the watcher option on the parser for config file.

Can you add request matching by json content?

The host argument is not working

Hello,

While trying to dockerize the project (see reference #8) I detected that it seems to be ignoring the -host argument when creating the address where the server listens to.

See reference:

killgrave/cmd/killgrave/main.go

Line 38 in b33b671

httpAddr := fmt.Sprintf(":%d", *port)

Thanks!

Add a delay option to add latency to the response

Context

One of the common benefits of using a mock server is its ability to add latency to its responses in order to simulate network issues. However, that option is not available yet on Killgrave, so it's a really simple but very worthy feature to implement.

Proposed implementation (UPDATE: #32 (comment))

A new field delay under the response section (within imposter) can be created and taken into account when returning a response.

The initial implementation can be as simple as posible, for example, assuming the configuration value is always defined in a predefined unit (let's say milliseconds -ms-).

Then, that implementation can be improved in order to allow the user define the value unit (ns, ms, s...) with a predefined format (i.e. 500ms).

For those interested on doing it directly that "best way", please let us know (here on the issue) what's your proposal (the one mentioned above -500ms- or some other) to define the delay value and unit.