On March 17 we enabled the mock-response policy which provides a quick way to make an API callable without a functional backend service. The policy has a simple signature:
<mock-response status-code="code" content-type="media type"/>
We have now made it even easier to use it by providing a user interface as well. The policy can be applied to every section, but its typical usage scenario is on the inbound path to provide a response instead of the backend service.
To configure mocking from the Azure Portal, open an API Management instance, and then under the APIs section, open an API. Then, for the scope of either All operations or any particular operation, open the Inbound processing editor. A new tab titled Mocking is now available:
Once static response mocking is enabled, the user can choose what response should be returned. If done on an operation and sample responses or schemas are defined for it, then they will be listed at the top of the list. Additionally the policy can also return any valid HTTP code with an empty body.
If the response code is not listed, it is possible to simply type in a new code:
Which will then be listed as “User defined status code”.
When mocking is enabled it will be indicated on the API diagram using a yellow warning bar at the top and by shading all policies below the mock-response one. This is because mock-response will halt the execution of the policy pipeline and return a response immediately.
The warning is currently shown only at the scope at which the policy is applied. For example, if it is applied at the API level and the user is viewing an individual operation, no warning will be shown and the editor will also not show the policy. However, inheritance from the base can still make the policy execute. We plan to provide smart warnings that detect these situations and warn users to avoid unintentional breaking of the policy pipeline.