Best practices for mocking/simulating API responses for 3rd party dev/test purposes?

[#1]

Hello. We are developing a public API for 3rd parties. For background & context: We have a complicated SaaS offering that is advanced and takes a long time to learn. However, we want to enable 3rd parties to create integrations with our core software in order to provide good user experiences... but we don't necessarily want to require all of those 3rd parties to have to become experts on our core software just to tell if their integrations are working correctly or not.

What is the best practice for handling this? If you look at companies like Stripe, they have settings like "test mode". Would "test mode" just stub/shim/mock the underlying API behavior?

Two strategies I'm thinking of in order to solve this issue include:

1. Creating a "test mode" for our public APIs wherein a 3rd party developer can specify that they want to run in "test mode". They would also pass in a "test mode state ID" (so that they can get the expected responses back that match up with a list of test mode states that they should account for in their integration).

2. Creating "environment creation" APIs that allow the developer to put an instance of our backend software into whatever states they should test for in their integrations.

Any other thoughts? And are there any tools in Apigee to help with this?

[madhans]

A way to do this is to deploy the "test" mode APIs in an environment of its own eg., sandbox so that the "test mode" is assumed and need not be specified. This allows "prod" to be "prod".

The SmartDocs in DevPortal can point to the "sandbox" environment running "test mode".

Mocking APIs by itself can be done using the AssignMessage policies to return hard-coded response based on the current "environment" (flow variable exists).

Sophisticated mocking can be done using node.js.

[parna]

The amok tool can be used to build the mocks as well