Use case – REST

Use case: REST

Create a REST project

Creating a new mocked REST project is easy! Click on the “New project” button on the project overview page to start creating a new REST project. Choose the project type to “REST”, give the project both a name and a description and then click on the OK button.

Congratulations! You have just created your first REST mock project!

Upload API specifications

Mocked REST services can be created in multiple ways. Once a REST project has been created, you can either create mocked REST services manually or upload an API specification. Creating mocked REST services manually is easily done by creating an application and from there create each individual service. Castle Mock can also create and mock web services by uploading a API specification for an already defined REST API.

Castle Mock supports three different API specifications:

  • RAML
  • Swagger
  • WADL

The upload page also contain the option to generate mocked response for every new mocked service being created. When checked, new mocked responses will be created for each web service.

An API specification file can be uploaded multiple times. The services that are already defined will be left untouched. Castle Mock will create new mocked REST services if the API specification contains new service definitions. Services that once existed in the API specification file but has been removed, will be removed from Castle Mock as well.

For more information about either Swagger or RAML, please see the following webpages:

Create mocked responses

Multiple mocked responses can be created for each REST web service. Each mocked response has its status code and the response message. Header can also be defined and overwritten for mocked responses. The service can be configured that use different response strategy. A response strategy is the strategy of choosing which mocked response should be returned in the event of multiple mocked responses has been defined. There are currently two different response strategies:

  • Random: The random response strategy will choose a mocked response randomly.
  • Sequence: The sequence response strategy will return the mocked responses in a sequence. The sequence is defined in which order the mocked responses were created. The sequence will start from the beginning when it has reached its end.

A mocked web service has a mode. The mode will determine how the mocked web service will act. There are currently six different modes available:

  • Mocked: The Mocked mode will use the defined mocked responses.
  • Disabled: The Disable mode will disable the service. A service consumer will receive an error message if trying to invoke a disabled web service.
  • Forwarded: The Forwarded mode will forward all incoming requests for a web service to an external endpoint. This mode can be used when only some web service should be mocked, while the rest should go to the original endpoint.
  • Recording: The Recording mode will forward all incoming requests for a web service to an external endpoint and create a mocked response for the responses returned from the external endpoint.
  • Recording once: The Recording once mode will do the same as the Recording mode, but will only do it one time. Once it has been done, the web service will switch to Mocked mode instead.
  • Echo: The Echo mode will return the request as a response.

Mocked responses can use expressions. Expressions are used to define how data in a response can be generated. An expression will be parsed and replaced with generated random data each time a mocked response is being returned. For more information on how expressions works, please go to the expression page.

Forward requests and record responses

A web service can be configured to forward all incoming requests to the original endpoint and record all responses. This will allow you to quickly and easily create mocked responses.


All incoming requests and outgoing responses will be logged. All these can be viewed on the event page or on the event tab for each individual web service. Each logged event will contain information such as date, status code, body and headers.