Generate configuration using scaffold

You can get Imposter to create configuration files for you.

If you have an existing endpoint from which to record requests and responses, see the proxy documentation

If you have an OpenAPI specification or a WSDL file, Imposter can 'scaffold' a mock based on the resources and methods it contains.

If you don't have any of these, it's easy to create the configuration using the guide.

Prerequisites

• Install the Imposter CLI

Scaffolding from an OpenAPI specification

Let's start with a simple OpenAPI file:

# petstore.yaml
---
openapi: "3.0.1"

info:
  title: Sample Petstore service
  version: "1.0.0"

paths:
  /pets:
    get:
      responses:
        '200':
          description: Returns all pets from the system
          content:
            application/json:
              schema:
                type: array
                items:
                  type: object
                  required:
                    - id
                    - name
                  properties:
                    id:
                      type: integer
                    name:
                      type: string
              examples:
                itemsExample:
                  value:
                    [
                      { "id": 101, "name": "Cat" },
                      { "id": 102, "name": "Dog" }
                    ]

Store this as a file named petstore.yaml.

Imposter can generate a configuration file from this specification:

$ imposter scaffold

found 1 OpenAPI spec(s)
generated 1 resources from spec
wrote Imposter config: /Users/mary/example/petstore-config.yaml

Look in the directory where you started Imposter and you will see a new file:

$ ls -l
-rw-r--r--  1 mary  wheel    79B  8 Sep 15:44 petstore-config.yaml
-rw-r--r--  1 mary  wheel   800B  8 Sep 15:44 petstore.yaml

The petstore-config.yaml file is the Imposter configuration file:

# petstore-config.yaml
---
plugin: openapi
specFile: petstore.yaml

resources:
  - method: GET
    path: /pets

Note that the HTTP method and path from the specification have been picked up. Since the openapi plugin is being used, when a request is made to this resource, the examples from the OpenAPI specification will be used.

Testing the mock

In the same directory as the files above, start Imposter:

$ imposter up

Starting mock engine 3.0.4
Loading configuration file: /opt/imposter/config/petstore-config.yaml
Adding mock endpoint: GET -> /pets
Adding specification UI at: http://localhost:8080/_spec
Mock engine up and running on http://localhost:8080

Imposter read the configuration files and a mock of the API is now running at http://localhost:8080

Call the mock:

$ curl http://localhost:8080/pets

[{"id":101,"name":"Cat"},{"id":102,"name":"Dog"}]

Imposter served the response based on what it captured.

Matched resource config for GET http://localhost:8080/pets
Setting content type [application/json] from specification for GET http://localhost:8080/pets
Serving mock example for GET http://localhost:8080/pets with status code 200 (response body 49 bytes)

Making changes

You can, of course, edit the configuration file so the mock behaves differently. When you change either the configuration file or response file, the Imposter CLI will restart to reflect your latest changes.

Scaffolding from a WSDL file

If you have a WSDL file, Imposter can scaffold a SOAP mock configuration from it.

Let's start with a WSDL file named petstore.wsdl that defines a getPetById operation.

Run the scaffold command:

$ imposter scaffold

found 1 WSDL file(s)
generated 1 resources from WSDL
wrote Imposter config: /Users/mary/example/petstore-config.yaml

The generated petstore-config.yaml file will look like this:

# petstore-config.yaml
---
plugin: soap
wsdlFile: petstore.wsdl

resources:
  - method: POST
    operation: getPetById

The SOAP operations from the WSDL file have been used to generate the mock resources. Since the soap plugin is being used, Imposter will generate responses based on the schema/XSD types defined in the WSDL.

Testing the mock

In the same directory as the files above, start Imposter:

$ imposter up

Imposter will read the configuration files and start a mock of the SOAP service. You can then send SOAP requests to the mock endpoint.

Learn more about SOAP mocking in the SOAP plugin documentation.

What's next

Learn how to use Imposter with the Configuration guide.