- Clone this repo:
git clone https://github.com/Optum/mockiato.git && cd mockiato - Set secret for JWT:
echo MOCKIATO_SECRET="<REPLACE>" > .env - Start Mockiato & MongoDB:
docker-compose up - View the app at http://localhost:8080 or the API documentation at http://localhost:8080/api-docs
- Use the '...Register an account here.' link to register as a mockiato user and log in.
Note:-
- To use private NPM registry you need to provide build argument REG_URL(private registry url) in docker build or docker-compose build commands.
- If you run the project locally (npm start) without docker you can use .npmrc file to download packages from private NPM registry. If you don't create .npmrc file NPM packages will be downloaded from public NPM registry (https://registry.npmjs.org/) by default.
This quick-start makes some basic assumptions on how you want to run the application. For other possible configurations, please see the next section.
Mockiato can be configured with the following environment variables. These can be set globally or in a file called .env in the project root directory.
| Option | Example | Description |
|---|---|---|
| MOCKIATO_SECRET | Required. Used to sign and verify JSON Web Tokens | |
| MOCKIATO_AUTH | local | The auth strategy to use. Defaults to "local" |
| MONGODB_HOST | localhost | The hostname for your Mongo instance |
| MONGODB_USER | admin | The user to connect to Mongo with |
| MONGODB_PASSWORD | The password for the Mongo user | |
| MOCKIATO_ADMIN | The admin user id | |
| MOCKIATO_ARCHIVE | 0 0 1 * * | The time interval for archive service to delete permanently. The value is Cron-style Scheduling type |
Mockiato is a web-based platform for API virtualization. Mockiato was developed at Optum to enable test automation, and can simulate REST APIs, SOAP services, and message-oriented middleware.
Mockiato can generate realistic data for testing, and export it to JSON, XML, or CSV. Mockiato creates virtual endpoints that simulate your production APIs. These virtual services are ideal for testing, sandboxing, knowledge transfer, and driving rapid development.
Mockiato is built on open-source technologies like Node.js and MongoDB, and was designed API-first with cloud readiness in mind. It exposes a RESTful API to programmatically interact with your services, as well as a modern web interface and command-line client.
Mockiato is comprised of 3 basic architectural components: a web-based user interface, a REST API for managing services, and a Mongo database.
Mockiato provides a simple, intuitive interface for managing virtual services. Built on AngularJS, this single-page application acts as a client to a Mockiato server.
In Mockiato, virtual services are considered resources. A REST API is exposed to facilitate CRUD (create, read, update, delete) operations on these resources.
For more information on the methods available in the API, please see our Swagger documentation.
All of the data that comprises a virtual service (base path, request data, response data, etc.) is stored in a Mongo database.
Please see the next section for more information on the data models behind Mockiato.
Mockiato structures data according to 4 basic models: a service, a request / response pair, a group, and an owner.
The service model is the primary entity, and the remaining 3 are sub-components of it. The service is comprised of a base path, type (e.g. SOAP, REST), name, owner, group, and a set of request / response pairs.
A request / response pair holds all information necessary for request matching (headers, status codes, HTTP methods, relative paths, request bodies, response bodies, etc.) At least one RR pair should be associated with a service for matching to occur, but many can run on a single service. For example, one service running on base path /v2/pets could have 2 RR pairs: one for creating a pet (e.g. a POST with some request data), and one for retrieving the pet (e.g. a GET with the pet ID as relative path).
Formerly known as a "system under test", a group is a convenient way to organize services. Think of it like a tag; it's just a way to say "these services belong together". It has only 2 fields: a generated ID and a name. The name is prepended to the base path of your virtual service. For example, a service with basepath /v2/pets in the group "test" will run in Mockiato on the base path /virtual/test/v2/pets.
The service owner is the person who created the service. If Mockiato is running with the LDAP authentication strategy, then the non-ID fields for the owner model are simply a username and email address. These are pulled from AD automatically on your first login.
The Mockiato team is open to contributions to our project. For more details, see our Contribution Guide.