API Mocking Service Release Notes

You can now change the server URL without the make public toggle automatically unchecking.

The /link endpoint was replaced by the new /links endpoint. For more information, refer to Mocking Service 2 API Endpoints.

The mocking service is now permanently enabled and you no longer need to define a mocking service URI in your specifications.

You can now open your projects without getting a warning to update to remove the mocking service URI.

You can now successfully test dependencies using the Mocking Service.

You can now use the cookie query parameter when defining an apiKey security scheme.

You now see the correct header values when sending a request.

Added support for the MS2-Example behavioral headers. MS2-Example allows you to choose a specific response example if your endpoint defines more than one example for the same status code.

Fixed an issue in the mocking service where URI parameters were not working correctly in RAML.

If an API specification written in OAS 3.0 uses an OAuth 2.0 security scheme, the mocking service requires an authorization header in each request.

The MS2-Delay behavioral header now takes a maximum value of 10000 milliseconds (ms), and now follows this behavior:

The mocking service returned an Invalid schema for content type application/xml error message for POST methods when these two conditions were met:

#%RAML 1.0
title: Regex-Test

mediaType: application/xml
types:
  xml:
    properties:
      zip:
        type: string
        pattern: (\d{5})
/test:
  post:
    body:
      application/xml:
        type: xml
    responses:
      200:

The mocking service would fail to start if a project contained any files with filenames that contained characters not allowed in URLs.

The mocking service was not validating file types when files in mock POST requests were uploaded.

The mocking service returned an Invalid schema for content type application/xml message when an enum was used in POST requests for which the response body was declared as application/xml.

The mocking service returned an Invalid schema for content type text/xml message when the content type for an XSD file in the body of a POST request was declared as text/xml.

The mocking service returned the wrong example in cases such as the following: in an API specification written in RAML, a type is defined with an example, but a response that uses the type overrides the example with an !include directive. Rather than use the included example in the response, the mocking service used the example from the type definition.

#%RAML 1.0
title: Example API with types and resources to showcase how examples look.
mediaType:
 - application/json
types:
  ExampleRoot:
    properties:
      string:
        type: string
        example: Internal Example
/foo/example:
  get:
    responses:
      200:
        body:
          type: ExampleRoot
/tmp:
  get:
    responses:
      200:
        body:
          type: ExampleRoot
          examples: !include external-example.raml

The mocking service was not validating an example-array header that was of type: string and not an array. Now, you can use valid strings in these headers.

March 7, 2020*

The mocking service was not validating DataType fragments that were referenced by a Library fragment that was in trun referenced by the root file in an API-specification project.

The mocking service did not return an error message if a required query parameter was missing or the value was empty.

In a particular case, the mocking service was not returning an example in responses, even though the example was defined.

It was not possible to import an XSD schema into API Designer in Anypoint Design Center through the mocking service.

If you set the authentication type to "Client Credentials" and then set a scope, the scope was not saved.

The mocking service returned empty responses instead of expected JSON responses in some cases, both in API Designer and in Exchange.

When the mocking service validated XML against an XSD schema that imported a namespace, it returned the following error message: Invalid schema for content type application/xml. Errors: URI has an authority component..

XML payloads in requests were not considered valid when a Union data type was used for XML schemas.

When the behavioral header MS2-Status-Code was used and set to 400, the mocking service returned the example that was defined for status code 200.

In API Console, the names of query parameters were being populated from parameter identifiers in parameter definitions, not from the parameter names. This problem occurred for API specifications written in OAS 2.0.

The API Console and the mocking service were adding invalid tags to XML examples.

Though multiple examples were defined for an endpoint, the mocking service always used the same example, rather than randomly selecting one to use.

When an OAS API specification did not define any consuming media type for a specific endpoint, the mocking service failed.

[SE-8276] - Issues with Design Center

[SE-8614] - Request header 'Accept' failing when application/xml is present before application/json

[SE-8666] - Mocking service for OAuth 2.0 requires users to provide both authorization header and access token

[SE-8745] - Mocking service required parameters are allowed to be left out

[SE-8790] - Mocking Server Validation on Message Body

[SE-8999] - RAML in Design Center: Unexpected token A in JSON at position 1

[SE-9588] - Mock Service returns 404 for paths with hyphens in 3rd level resource name

[SE-9830] - Mock service api always return 400

[SE-9990] - JSON Schema defined inline in Design Center RAML gives error, OK on Studio

[SE-10045] - Incorrect Datetime-only format error when trying on mocking service from design center

[SE-10194] - RAML issue with optional enum type headers

[SE-10222] - additionalProperties=false in RAML are ignored by Design Center and exchange Mocking services.

The mocking service did not return messages for the 400 response in the correct styling.

TLS 1.0 and 1.1 were still supported. Now, only 1.2 is supported.

Invoking a resource that required the uriParameter (e.g., “/main/{attname}”) returned the example response for root instead of the defined example.

Invoking a resource that required a uriParameter and then using the example parameter in a GET or PUT method resulted in a response containing the complete API specification.