sakapun/apisprout repository overview

A simple, quick, cross-platform API mock server that returns examples specified in an API description document. Features include:

• OpenAPI 3.x support
• Load from a URL or local file
• Accept header content negotiation
  • Example: Accept: application/*
• Prefer header to select response to test specific cases
  • Example: Prefer: status=409
• Server name validation (enabled with --validate-server)
• Request parameter & body validation (enabled with --validate-request)
• Configuration via:
  • Files (/etc/apisprout/config.json|yaml)
  • Environment (prefixed with SPROUT_, e.g. SPROUT_VALIDATE_SERVER)
  • Commandline flags

Usage is simple:

# Load from a local file
apisprout my-api.yaml

# Load from a URL
apisprout https://raw.githubusercontent.com/OAI/OpenAPI-Specification/master/examples/v3.0/api-with-examples.yaml

⁠Enable CORS on all requests from all origins, a handy feature for testing/development environment

apisprout -c my-api.yaml

⁠Docker Image

A hosted API Sprout Docker image⁠ is provided that makes it easy to deploy mock servers or run locally. For example:

docker pull danielgtaylor/apisprout
docker run -p 8000:8000 danielgtaylor/apisprout http://example.com/my-api.yaml

Configuration can be passed via environment variables, e.g. setting SPROUT_VALIDATE_REQUEST=1, or by passing commandline flags. It is also possible to use a local API description file via Docker Volumes⁠:

docker run -p 8000:8000 -v localfile.yaml:/api.yaml danielgtaylor/apisprout /api.yaml

⁠Installation

Download the appropriate binary from the releases⁠ page.

Alternatively, you can use go get:

go get github.com/danielgtaylor/apisprout

⁠Contributing

Contributions are very welcome. Please open a tracking issue or pull request and we can work to get things merged in.

⁠Release Process

The following describes the steps to make a new release of API Sprout.

1. Merge open PRs you want to release.
2. Select a new semver version number (major/minor/patch depending on changes).
3. Update CHANGELOG.md to describe changes.
4. Create a commit for the release.
5. Tag the commit with git tag -a -m 'Tagging x.y.z release' vx.y.z.
6. Build release binaries with ./release.sh.
7. Push the commit and tags.
8. Upload the release binaries.

⁠License

Copyright © 2018 Daniel G. Taylor

http://dgt.mit-license.org/⁠