API Designer (Crowd) Release Notes

API Designer now supports the AML Modeling Framework (AMF) 5.6.3-0.

You now see $ref suggestions under user schemas on AsyncAPI 2.6 API Specifications.

API Designer now supports the AML Modeling Framework (AMF) 5.6.3.

You can now use a Solace server without triggering warnings in the AsyncAPI Best Practices ruleset.

This product has a refreshed UI.

API Designer now supports the AML Modeling Framework (AMF) 5.6.2.

You now see the defaultContentType field on the auto-complete suggestions on an AsyncAPI 2.6.

API Designer now supports the AML Modeling Framework (AMF) 5.5.4.

API Designer now supports the AML Modeling Framework (AMF) 5.5.3.

API Designer now supports AsyncAPI 2.6.

API Designer now supports the AML Modeling Framework (AMF) 5.5.2.

API Designer now supports the AML Modeling Framework (AMF) 5.5.1.

API Designer now supports the AML Modeling Framework (AMF) 5.5.0-0.

API Designer now supports the AML Modeling Framework (AMF) 5.5.0.

You can now select the project’s branch before opening your projects in Design Center.

API Designer now supports the AML Modeling Framework (AMF) 5.4.9.

Validation of Governance rulesets is improved. If you enable manual validation mode, you now see a No conformance issues to show after validation message on the Project Errors panel after successful validation.+ If the validation fails, you can copy the details of the error to your clipboard to see the non-validating ruleset.

Project owners and organization administrators can now transfer their ownership to a different organization member. For more information, see Design Center Permissions.

API Designer now supports the AML Modeling Framework (AMF) 5.4.5.

You can now narrow int64 base types to int62 base types without getting an invalid type inheritance base type error message.

You can now disable auto-validation of Governance rulesets to run a single validation for each ruleset rather than triggering multiple automatic validations that can exhaust your resources. For more information, see Improving Ruleset Validation.

You now get suggestions for !include tags in RAML specifications and $ref properties in Async APIs.

API Designer now supports the AML Modeling Framework (AMF) 5.4.4.

You now get a message specifying we don’t support XML 1.1 when referencing a XML 1.1 file.

API Designer now supports the AML Modeling Framework (AMF) 5.4.3-0.

API Designer now supports the AML Modeling Framework (AMF) 5.4.2-4.

You can now parse a union of three or more members that are not nested under a different union.

API Designer now supports the AML Modeling Framework (AMF) 5.4.1-4.

API Designer now supports the AML Modeling Framework (AMF) 5.3.0.

You now see the correct error message when using different formats for two examples of the same type.

API Designer now supports the AML Modeling Framework (AMF) 5.2.6.

You now see an error message when using a JSON schema with type inheritance properties.

You can now disable the API Designer GitHub Integration. For more information, see Disabling the GitHub Integration.

API Designer now supports the AML Modeling Framework (AMF) 5.2.5.

You now see an error message when a RAML type is invalid. (For example, in
properties:
products []
you now see [] is not a valid type)

Design Center now validates that the property type and the discriminatorValue field are the same.

API Designer now supports the AML Modeling Framework (AMF) 5.2.4.

When defining an ExternalFragments property in a OAS specification, it now links to the referenced node properly.

You can now create API Fragments in RAML, OAS 3.0, and JSON Schema format. For more information, see Create and Publish an API Fragment in the Text Editor in API Designer

API Designer now supports the AML Modeling Framework (AMF) 5.2.3.

API Designer displays an error message when you publish an asset with invalid values in the Business Group ID, Asset ID, or Asset name fields in the Publishing to Exchange dialog.

You can now see the correct information when clicking the Exchange tab on the sidebar in the read-only asset page.

You can now use control + F to search for strings in a project with errors without crashing the browser.

The exchange tab is no longer visible when viewing code from Exchange.

The Design Center User Interface is updated for better accessibility.

New Design Center Business Group and Project Level permissions are added for more granularity when sharing projects. For more information see Design Center Permissions.

API Designer now supports the AML Modeling Framework (AMF) 5.2.2.

The user interface navigation is updated for better accessibility

You now get an error message when publishing an invalid asset in exchange.

You can now see a visual indicator of the keyboard focus when navigating through the visual editor mode.

API Designer now provides support for AML Modeling Framework (AMF) 5.2.1.

When creating an API Spec in the Visual editor mode, you can now successfully delete and add new content in the Example area of a data type.

You can now navigate through the Filter menu of a project with your keyboard.

You can now properly see the values defined for enum types in the Query parameters section in the summary page of the API documentation.

You can now successfully generate a request URL with a defined path parameter.

When defining AnnotationType and properties in RAML, you no longer get incorrect suggestions.

When suggesting boolean fields in OAS2, you no longer get incorrect suggestions that add double quotes.

API Designer now provides support for AML Modeling Framework (AMF) 5.2.0.

You no longer get validation errors when defining additional properties.

Added a security layer to the API console, so that only registered domains are reachable.
For more information, see the Allowlisting Trusted Domains documentation.

You now get an email notification when your API fails conformance to rulesets your organizations validates.
For more information, see the Adding Dependencies to an API-Specification Project documentation.

You can now edit the API Version field when publishing a project to exchange.

The Publish button is updated for better accessibility, and a new Exchange tab is added to the sidebar.

You can now use special characters when renaming branches on projects synced to GitHub.

You can now have multiple response status codes on API Visual Designer.

API Designer now supports AML Modeling Framework (AMF) version 5.1.0.

When defining multiple keys in an OAS 3 spec, they now show the correct documentation and labels associated with those fields.

When entering the Try It panel, the Client ID field no longer shows an error message, and the warning messages are fully and correctly displayed

You can now click on Clone, Edit, and Delete using assistant technologies.

You can now see a visual indicator of the keyboard focus when navigating through API Specification fragments.

You can now enter values for query parameters without losing focus.

You can now extract the body of your project to a new data type without getting an error message.

You can now navigate through UI elements with the keyboard.

When using the securedBy and SecuredByCompletionPlugin fields with RAML files, you no longer get incorrect suggestions.

When using API annotations that generate a YAML Map, you will now be suggested to include a break line at the end instead of an empty space.

You can now navigate through the Exchange Dependencies panel using assistant technologies such as screen readers.

When clicking View Code on a published exchange asset related to a no longer existing branch, you no longer receive an error message.

When clicking View Code on a published exchange asset, you no longer receive an error message.

When renaming your branches with a $ character, you no longer receive an error message.

When renaming or cloning a project, you now need to enter a name before confirming.

Design Center now includes links to our Github Synchronization documentation page.

You now have more granularity in API Designer permissions.

All user interface components have been updated to APID Components v3.

The user interface navigation is updated for better accessibility.

You can now see suggestions under the uses property in a library fragment when defining data type properties in RAML Data Type fragments files.

API Designer now supports AML Modeling Framework (AMF) version 5.0.10.

When you use $ref in OAS Parameter Specifications, you no longer receive an error message.

When using the expander toggle (>) on the Errors panel, you now expand the item you selected instead of multiple items.

When you click Cancel on a create dialog, you no longer receive an error message.

You can now navigate through create menus without losing focus.

GitHub Synchronization is a version control tool that maintains API specifications existing in several locations. Use GitHub Synchronization to enable two-way synchronization between API Designer and your GitHub repository.

You can now re-name the main branch in adherence to our Inclusive Product Language Program.

You can now see suggestions when defining data type properties in RAML Data Type fragments files.

API Designer now supports AML Modeling Framework (AMF) version 5.0.9.

All AML Dialect JSON Schema integer types are now converted into long types to support larger numbers.

User interface terminology and navigation have been updated for better accessibility.

The text editor sidebar and editor shelf expander toggles (> and <) are no longer overlapped with other elements.

When you view code from Exchange in the text editor, you no longer receive a 'No zip file for gav' error.

The visual editor UI now validates the resource name field and disallows entry of invalid characters such as double quotes ("), carat (^), and percent (%).

You can now successfully import an example from the visual editor.

API Designer now supports AML Modeling Framework (AMF) version 5.0.8.

In OAS3 APIs with references to endpoints that have references to schemas, second-level references with valid paths are resolved properly.

When you convert a RAML API to OAS 2.0 and mediaType is defined for an endpoint, the text editor uses the endpoint’s mediaType rather than the default.

A new ruleset dependency type is introduced in this release to enable you to validate your API specifications against rulesets cataloged in Exchange.

The visual editor UI refresh rate has been improved.

API Designer now supports AML Modeling Framework (AMF) version 5.0.6.

When you declare a security scheme in a RAML library, use it in an API specification, and then convert the RAML specification to OAS, the OAS specification is now generated with valid security scheme information.

When you define both date and pattern formats for OAS types, API Designer shows a warning that the pattern property might be ignored if the date format already defines a standard pattern.

Boolean schemas are now parsed for JSON schema draft-06.

Security scheme fragments with media type defined at the global level are now validated properly.

Code suggestions are now properly shown for OAS 3.0 specifications that use externalDocs regardless of the position of the cursor.

The hover text is now properly shown for OAS 3.0 specifications that use externalDocs.

API Designer now provides support for AML Modeling Framework (AMF) 5.0.4.

AMF parser validations no longer show duplicate examples for error codes.

API Designer now provides support for AML Modeling Framework (AMF) 5.0.2.

OAS 3.0 specification properties with nullable fields set to true are now correctly validated when sent in payloads.

In OAS 3.0 specifications, 'responses' node autocomplete suggestions no longer include the New Response option.

In RAML 1.0 specifications, autocomplete suggestions now correctly show for objects inside array types.

In RAML 1.0 specifications, autocomplete now correctly shows prefix suggestions.

In RAML 1.0 specifications, autocomplete no longer suggests duplicates for resourceTypes and traits.

API Designer now provides support for AML Modeling Framework (AMF) 5.0.1.

AMF parser validations no longer incorrectly highlight the origin of the document. Validations now highlight the correct line of the validated shape or fragment.

When you initiate the import of a ZIP file but do not choose a file, the Import button is no longer enabled.

The tooltip for a deprecated dependency is now displayed correctly.

You can now create, import, and edit AsyncAPI specifications in API Designer. See Event-Driven API (AsyncAPI) Support Release Notes.

API Designer now provides support for AML Modeling Framework (AMF) 4.7.8.

Inheriting from array types no longer results in an Incompatible types [array, array] validation error.

Including a disjoint UnionShape within the examples node of a schema no longer results in an expected type: X, found: Y error.

API Designer now provides support for AML Modeling Framework (AMF) 4.7.7.

The union and nil types are now parsed with equivalence.

Validation no longer fails for required facets in properties containing the nillable shorthand type. For example, the following code no longer results in Error: Property 'required' not supported in a RAML 1.0 string node:

#%RAML 1.0
title: APIMF-2975

types:
   Test:
     properties:
       name:
         required: false
         type: string?

AMF now saves properties declared in required but not present in properties. For example, the following code no longer results in an ignored address property:

{
    "$schema": "http://json-schema.org/draft-04/schema#",
    "type" : "object",
    "properties": {
        "name": {"type": "string"},
        "age": {"type": "integer"}
    },
    "additionalProperties": false,
    "required": [
        "address"
    ]
}

Inner document path suggestions no longer contain a trailing slash.

API Designer now provides support for AML Modeling Framework (AMF) 4.7.6.

RAML 1.0 definitions containing duplicate property names were incorrectly validated. For example, the following definition did not result in an error:

#%RAML 1.0
title: test-example
version: v1

types:
  failing:
    type: object
    properties:
      duplicate: string
      duplicate?: string
    example:
      duplicate: "hello error"

Error: Duplicated property names: duplicate

Autocompletion in OAS specifications containing parameters tags now suggests "info" (instead of "in") for root nodes.

Autocompletion in OAS specifications is now correct for version tags when subsequent text exists.

The time to open the Publish to Exchange dialog is improved for projects containing several files and dependencies.

The XML 'name' property was ignored in the example XML payload generated via API Console.

Opening a project occasionally resulted in a non-completing Loading…​ message. The browser console displayed the following error:

Uncaught DOMException: Failed to execute 'importScripts' on 'WorkerGlobalScope'

When publishing assets to Exchange takes more than 1 minute, the following message is now displayed:

Error publishing to Exchange: Request timed out due to project size. Asset may have been successfully published. Please verify in Exchange.

Options were not rendered in API Console for schema properties containing the oneOf keyword.

RAML 1.0 inline unions in extensions now parse correctly.

#%RAML 1.0
title: example API to be extended

types:
  TestObject:
    type: object

/test:
  get:
    responses:
      200:
        body:
          application/json:
            type: TestObject

#%RAML 1.0 Extension
extends: /api.raml

types:
  TestObject:
    properties:
      unionDate: datetime-only|nil
    example:
      unionDate: null

/test:
  get:
    responses:
      200:
        body:
          application/json:
            type: TestObject

Error: 'unionDate' should be string 'unionDate' should match some schema in anyOf

Adding an enum property to an extension resulted in duplicate values in API Console.

When trying to use the same library defined in an API specification more than once, the following error was returned:

Error: Libraries must be applied by using 'uses'

API Designer now provides support for AML Modeling Framework (AMF) 4.7.5.

OAS 2.0 security scheme definitions that do not contain name and in required fields now result in warnings:

Warning: Property 'in' is required in a OAS 2.0 apiKey node
Warning: Property 'name' is required in a OAS 2.0 apiKey node

Autocompletion now displays correct options for example nodes that include example fragment files.

Autocompletion now displays correct RAML method names for endpoint name nodes.

Enum values declared in an array type were not displayed in the Documentation panel.

When publishing to Exchange, API projects with a large number of files intermittently resulted in the following HTTP 502 timeout error response:

Error publishing to Exchange: Unknown error

In API Console, selecting a body content type of application/xml created an invalid payload. The following error was displayed:

400 Bad Request

It was not possible to scroll through large amounts of Exchange dependencies.

API Console displayed a validation error when entering fractional numbers as query parameters.

API Designer now provides support for AML Modeling Framework (AMF) 4.7.4.

The RAML datetime-only validator now returns an error for years with over four digits.

Does not suggest incorrect options within a type definition when defining facets.

Does not suggest in-use options.

Suggests only description for the description field of a parameter.

Provides suggestions if a colon is after your cursor.

API Language Server (ALS) would not return an error payload for a Serialization request while a workspace was still initializing. ALS now returns an error payload if the Serialization request can’t be validated.

API server descriptions are now present in the Documentation pane with their servers.

API Designer now provides support for AML Modeling Framework (AMF) 4.7.3-1.

Invalid discriminator mapping values now result in a warning. For example, the invalid value in the last line of the following snippet results in Warning: Unresolved reference 'null'.

openapi: "3.0.0"
info:
  version: 1.0.0
  title: 1-api
paths: {}
components:
  schemas:
    Dog:
      type: string
    Cat:
      type: string
    Animal:
      oneOf:
        - $ref: '#/components/schemas/Dog'
        - $ref: '#/components/schemas/Cat'
      discriminator:
        propertyName: petType
        mapping:
          invalid: 'null'

In RAML 0.8, specifying a relative reference (for example, !include common/400.example) instead of the intended absolute reference (for example, !include /common/400.example) results in an error:

Error: Resource common/400.example not found

The parser now resolves spaces in values with !include tags, such as the following:

title: !include /title file.yaml

Schemas with schemaLocation values containing .xsd files resulted in the following incorrect warnings:

Unreferenced file: This file is not referenced by the root file

Incorrect strings replaced the response section title in the Responses section. The title text is now displayed as Example in all cases.

OAS specification 'description' and 'example' values did not display in the Documentation section.

Mocking service requests did not successfully complete due to certain missing JSON headers.

API Console did not display the correct property type for arrays declared with the [] qualifier (for example, string[]).

API Console did not display the correct information for schema definitions containing the anyOf keyword, such as in the following snippet:

"companyType": {
            "anyOf": [
              {
                "type": "string",
                "maxLength": 10,
                "description": "The legal name of the given company.",
                "enum": [
                  "EU"
                ]
              },
              {
                "type": "string",
                "description": "Any future added type",
                "maxLength": 10
              }
            ]
          }
        },

item.companyType
Any

API Designer now provides support for AML Modeling Framework (AMF) 4.7.2.

RAML nillable shorthand string? types were not recognized in uriParameters, queryParameters, or headers maps. The following error was displayed:

Cannot declare unresolved parameter

Previously published Exchange dependencies failed to load in API Designer when importing an API specification or fragment and creating branches containing / (for example, features/mybranch).

For some projects in the project list, the Created By field displayed UUIDs instead of names.

The mocking service returned an Invalid Schema error after correcting ref paths in an .xsd schema file.

API Designer now provides support for AML Modeling Framework (AMF) 4.7.1., which improves validation of object payloads inside enums.

#%RAML 1.0
title: Some API

types:
  AnimalWithPaws:
    properties:
      name: string
      pawsCount: number
  AnimalWithHoofs:
    properties:
      name: string
      hoofsCount: number
  Animal:
    type: AnimalWithPaws | AnimalWithHoofs
    enum:
      - name: Cat
        pawsCount: 4
      - name: Horse
        hoofsCount: 4

By design, the visual editor will not add the URI parameter (for example, bookId) to the resource name (for example, /book).

Please add it to the resource name input as needed, e.g /book{bookId}

From the visual editor, the following error was returned after selecting the Access token (browser flow) grant type and attempting to authorize an OAuth access token:

Cannot GET /node_modules/@advanced-rest-client/oauth-authorization/oauth-popup.html

In the text editor, renaming an array type with the Rename Symbol action resulted in a non-array type name.

#%RAML 1.0
title: My API with Types "person"
types:
  person:
    description: this is person's description
    properties:
      firstname: string
  manager:
    type: string
  Alertable: manager | person
/person:
  get:
    responses:
      200:
        body:
          application/json:
            type: person[]
            example:  |
              [{
                "firstname": "person"
              }]
/person/{manager}:
  post:
    body:
      application/json:

In the text editor, autocomplete incorrectly suggested the responses tag after entering "r". The error occurred when typing under the queryParameters: node.

The API Designer text editor now supports the following actions:

The AML Modeling Framework (AMF) parser is now version 4.7.0.

OAS 3.0 code generated when switching from the visual editor to the text editor was invalid and could not be published to Exchange.

"produces": [
  "application/json"
],

Error: Property 'produces' not supported in a OAS 3.0 webApi node

Publishing an asset to Exchange and then deleting the project resulted in the option to edit the specification from Exchange. Selecting Edit spec resulted in the following error:

Project not found

Previously you could create a file with the reserved name, exchange.json.

Importing a ZIP file with a file named exchange.json located in a folder other than the reserved exchange_modules folder resulted in two added files named exchange.json.

The Documentation panel displays an incorrect type: number value if the value is 16 digits or larger.

16digits:
  type: number
  maximum: 9999999999999999

OAS 3.0 specifications with nullable fields generated unexpected anyOf keys when converted to RAML 1.0 specifications.

When using the Import from File option, importing a Mac-compressed ZIP file incorrectly added a reserved folder __MACOSX to the project.

When using the Import from File option with a ZIP file containing a single folder at root level (with the API specification content inside), the root level folder was not removed and was incorrectly imported into the created project.

When sorting projects by Name, Project Type or Last Update, the projects disappeared from the view.

After publishing a project via Publish to Exchange, the code suggestions were not displayed in the text editor.

API Designer now provides support for AML Modeling Framework (AMF) version 4.5.1. Version 4.5.1 enables JSON parsing recovery, which better validates JSON files with syntax errors. These errors are now more isolated, and more JSON content is now validated.

{
  "name": "john",
  "surname": "doe
  "age": "33"
}

Error: Syntax error : Expecting ',' but 'age'" found
Error: Syntax error : Expecting '"' but 'age'" found

Error: Syntax error : Expecting ',' but ' ' found
Error: Syntax error in the following text: 'doe'
Error: Syntax error : Unexpected '"' but ' ' found
Error: Syntax error : Missing ','

Errors were not being reported when publishing malformed OAS assets to Anypoint Exchange.

Moving files into renamed directories caused the following error:

<filename> is not a valid directory

The Documentation panel’s Operation ID URL did not match the selected server after loading an OAS 3.0 specification.

Specifications that did not define baseUri resulted in no endpoint URL documentation.

Support for boolean facet properties using JSON Specification Draft 4 or later.

Fixed an issue where nested resources where incorrectly displayed under the parent resource.

Fixed an issue with periods in the name of a forked branch.

Added warning message when loading a RAML specification containing OAS security schema types.

Fixed an issue where clicking the Edit spec button in Exchange caused an error.

Fixed a minor display issue.

When selecting a server to use for the mocking service, the URL displayed does not match the selection.

In some cases the endpoint URL may not display in the API specification’s documentation panel.

Added new dialogs for creating an API specifications and fragments.

For assets published to Anypoint Exchange, you can view the source code directly from Exchange by selecting View code in API Designer. By default the project opens in API Designer in read-only mode. If you have edit permissions and the project exists in Exchange, API Designer give you the option to edit the project.

Added hover tooltips that provides additional information about the nodes in an API specification or fragment.

Fixed an issue where data fragment was not shown in API Designer when imported into a library fragment.

Fixed an error in the AMF parser where maximum call stack was exceeded.

Fixed an issue where 404 errors were returns if a branch name contained a slash.

Fixed a YAML error when using the @type in a JSON example.

Fixed an issue where duplicating fragments resulted in a 400 error.

Fixed an issue where API Designer did not complete loading when opening a branch with no files in its root.

Fixed an issue where the branches dialog was not visible when no preview existed for the current selected file.

Fixed an issue where changing the extension of a file required a user interface refresh.

Fixed an issue in the visual editor where values in query parameters could not be set.

In the visual editor, fixed an issue with query parameters after creating an enum type.

RAML Unions

#%RAML 1.0
title: Secrets Provider
version: v1
baseUri: https://test.com/provider/
types:
  EncryptedResponse:
    type: object
    properties:
      encryptedKey:
        type: string
  sharedSecretUsernamePassword:
    type: object
    properties:
      username:
        type: string
  sharedSecretSymmetricKey:
    type: object
    properties:
      key:
        type: string
  SharedSecret: sharedSecretUsernamePassword | sharedSecretSymmetricKey
/path:
  get:
      responses:
        200:
          body:
            application/json:
              type: SharedSecret | EncryptedResponse
              examples:
                encrypted: |
                  {
                    "encryptedKey": "encryptedKey",
                    "cipherText": "cipherText"
                  }

RAML Version Base URI Parameter

#%RAML 1.0
title: Brown Google Admin Directory API
baseUri: https://localhost/services/cis/brown-google-admin-directory-api/v{version}

Fixed an issue where JSON schemas in RAML specifications were not displayed properly in the Design Center API Console.

Arrays defined in a RAML specification in Design Center were being treated as objects within Studio.

Importing resources failed if they contained invalid file names. API Designer now checks the validity of resources in a ZIP file and alters the filenames if necessary.

Fixed a bug where a file inside a folder did not suggest the correct module when using an !include tag.

You can have multiple files open simultaneously in API Designer’s text editor.

Using only one action, you can rename declarable objects everywhere they are used in a project that is open in the text editor.

When multiple media types were declared in a response body, the documentation pane sometimes did not list them all.

When multiple responses were declared for an API specification written in OAS 2.0, the documentation pane sometimes did not display all of the example responses.

The properties accessTokenUri and authorizationTokenUri in settings nodes were not validated in OAuth 2.0 security schemes.

The properties requestTokenUri, authorizationTokenUri, and tokenCredentialsUri in settings nodes were not validated in OAuth 1.0 security schemes.

Examples defined for queryString nodes were not appearing in the documentation pane.

The text editor incorrectly allowed the YAML multi-document tag ---. Now, the editor flags this tag as a syntax error.

#%RAML 1.0
title: api
---
/test:

The text editor did not correctly validate the use of security schemes that were defined in RAML SecurityScheme fragments.

#%RAML 1.0
title: API

securitySchemes:
  oauth_2_0: !include securitySchemes/oauth_2_0.raml

/users:
  get:
    securedBy: [ oauth_2_0: { scopes: [ USER ] } ]

#%RAML 1.0 SecurityScheme
description: |
  This API supports OAuth 2.0 for authenticating all API requests.
type: OAuth 2.0
settings:
  accessTokenUri:   https:/host/path/oauth2/access_token
  authorizationGrants: [ client_credentials ]
  scopes: [ ADMIN ]

You can highlight the names of declarable objects where they are used in a file.

#%RAML 1.0
title: Test Highlighting

types:
  person:  (1)
    type: object
    properties:
      name: string

/test:
  get:
    responses:
      200:
        body:
          application/json:
            type: person  (2)

#%RAML 1.0
title: Test Highlighting

types:
  person:  (1)
    type: object
    properties:
      name: string

/test:
  get:
    responses:
      200:
        description: person  (2)
        body:
          application/json:
            type: person  (3)

When you move a file into a folder that already contains a file that has the same name and extension, a new confirmation dialog asks whether you would like to cancel the move, keep both files, or replace the file that is already in the folder.

The text editor no longer validates projects that are in read-only mode.

In the text editor, the order of the data types presented in the documentation pane could differ from their order in a currently open API specification written in RAML.

In some cases, a header could be duplicated on the Try It page and, when an API specification was published to Anypoint Exchange, endpoints might display headers that were not defined for those endpoints.

A recursive shape was created from the merge of an endpoint and a resource type when both referenced the same type but in different ways: one referencing it from a library, the other referencing it through a type declaration.

The text editor reported an error if, in the settings attribute used by OAuth2, the scopes property was not set.

The text editor could fail to make suggestions if the root file of a project was being edited.

If the root file was selected in the text editor, it was possible for the documentation for referenced types not to appear in the documentation pane, although the type definitions in the referenced files did contain documentation.

If any parameter was defined as an enum and the default value was not the first value in the array, the mocking service replaced the first value with the default value.

In the text editor, the Import feature accepted files for which the names included back slashes.

Limited support for OAS 3.0

Changes to the documentation panel in API Designer:

New "go to" actions in the text editor

The text editor could not open an API specification that was written in RAML.

Enum values in a RAML API specification that was published to Anypoint Exchange from the text editor did not appear in the documentation of the specification in Anypoint Exchange.

The text editor did not detect duplicate keys if one of the two keys was surrounded by quotation marks.

In the documentation pane of the text editor, the table view of the Response body did not correctly translate the source view.

The text editor displayed the error message Internal error during validation for an API specification that was written in RAML.

In the text editor, when objects that contain arrays or collections were shown in XML in the documentation pane, the names of child elements were generated incorrectly.

For API specifications written in OAS 2.0, the Response section in the documentation pane showed the same response example for all response codes.

Examples defined at the property level of types were not included in examples at the resource level in the documentation pane of the text editor if a RAML API specification defined more than one endpoint.

The warning message Unable to load schema from 'http://schema.hropenstandards.org/4_0/common/json/meta/hros.json'. No schema request service available. appeared erroneously in the text editor for a particular JSON schema.

Fixed the "Unresolved reference" error for references to .yaml files in OAS API specifications.

The text editor now displays error messages and warnings in a new view that you can open by clicking a tab in the editor’s bottom-right corner.

The new status bar at the bottom of the text editor shows the name of the currently open file, the position of the cursor in the file, whether the file is the root file of the project, the language (RAML or OAS) that the current file is written in, and the type of project that you are working in.

API Designer did not publish a project to Exchange if the project contained a filename that included a space.

Attempting to update an Exchange dependency sometimes resulted in the error message 502 Bad Gateway.

Neither the Documentation pane nor the Try It panel were generating the correct XML example for element names that contained periods, such as [abc.xyz].

For API specifications written in OAS 2.0, the Documentation panel could display API Key twice in the Authorization method field if two security definitions were both defined as the apiKey type.

When the client ID or secret for a RAML API specification that included authorizationGrants: [client_credentials] was not visible in the Documentation pane, the Client ID or Secret field was also not visible.

The text editor sometimes failed to render methods and endpoints in imported OAS 2.0 API specifications.

Beginning with Anypoint Studio 7.5.0, users can edit API-Designer projects directly in Studio. If you are working in a project in the text editor in API Designer at the same time that someone using Anypoint Studio 7.5.0 or later is working in the same project, there could be save conflicts. As you work in the text editor in API Designer, the editor saves your project frequently if you have made changes since the last automatic save. However, if a user in Studio is working in the same project and saves changes before the next automatic save in the text editor in API Designer, the editor displays this message:

This branch has changed externally
A new commit has been made to this branch since your last save. We will use the changes from your repository and discard your latest updates.

The Exchange Dependencies pane lists RAML API fragments that have been added as dependencies in a project directly from Anypoint Exchange. Now, when a new version of a fragment listed in the Exchange Dependencies pane is published on Exchange, an icon appears next to the name of the dependency to notify you that the version you are using is deprecated. As in previous releases, follow these steps to use the new version in your project:

If an error occurs when you publish a project to Anypoint Exchange, the error message now appears in the publish dialog.

In the exchange_modules folder in projects in the text editor, there are two changes:

In some cases, the text editor reported that RAML trait fragments in an API-specification project included unresolved file references, even when the file references were correct.

The text editor displayed the error message "Error recursive shape" when a RAML API specification referenced an Exchange Library type.

The use of $ref caused the text editor to display error messages about unresolved file references when referenced files were in project subfolders and when they were in the top level folder.

In the visual editor, if a search in the filter field found results in the DATATYPES section, the RESOURCE section, or both, those sections were not automatically expanded if they were closed.

The new Filter field in the Files pane of the text editor can help you locate files in your project faster.

You can now import API specifications from Anypoint Exchange into the visual editor.

In the visual editor, you can proxy a request to a REST service by deselecting the shield in the top-right corner:

When you are working in the text editor on files written in RAML, you can now hold the command key and click on the file name in an !include tag to open that file.

When a line of text in a file in the text editor is underlined red, indicating that there are one or more errors in the line you can click in the line to see the error message or messages.

In the visual editor, changing a data type’s minimum and maximum lengths could result in these lengths being changed for other data types, too.

If you view the asset page for an API specification in Anypoint Exchange, you can click View Code to open the specification in read-only mode in the text editor of API Designer. The issue was that, if you tried to view different files in an API specification after entering read-only mode this way, the text editor displayed the error message "The requested resource could not be found."

API Designer did not flag as invalid cases in which a property was defined as a numeric or object type, but then overridden with type "any", which is less restrictive.

The text editor displayed the error message Should NOT be longer than n characters at …​ because it incorrectly invalidated inheritance in examples.

Some properties defined in API specifications written in RAML appeared in the Types section in the left pane of the asset page in Anypoint Exchange.

Endpoints were sometimes not grouped and listed correctly in the Documentation pane.

Microsoft Internet Explorer 11 closed unexpectedly when opening API Designer projects.

By default, files in a project that are not directly or indirectly referenced by the project’s root file are not published to Anypoint Exchange along with the rest of the project.

Figure 3. This is the dialog that provides the option to override the default or to cancel publication so that you can remove unreferenced files.

The text editor no longer suggests the usage facet for any types of RAML fragment other than ResourceType, Trait, Library, Overlay, and Extension.

In the text editor, files were allowed to be renamed to include characters that broke the process for publishing to Anypoint Exchange.

In the text editor, API specifications written in OAS 2.0 generated errors if their first line was composed of three dashes or if a line of three dashes followed directives.

---
swagger: "2.0"
info:
  description: This API is written in OAS 2.0.
  version: "1.0"
  title: api-in-oas

%YAML 2.0
%TAG !/directive/
---
swagger: "2.0"
info:
  description: This API is written in OAS 2.0.
  version: "1.0"
  title: configuration-exp-api-consul

In certain cases, starting a project from an existing example generated an error.

It was possible to create an OAS 2.0 (JSON) project named "exchange", which led to a malformed initial file because of the conflict with the metadata file "exchange.json".

In the Asset name field of the dialog for publishing projects to Anypoint Exchange, spaces were replaced by dashes.

The navigation icon in the Documentation pane appeared for all types of RAML fragment, rather than only for Library, Overlay, and Extension fragments.

A new filter dialog enables you to filter the list of projects in Design Center, in addition to filtering the list of projects in the existing search box at the top of the list.

Figure 4. You can filter on project type and range of time during which projects were last updated. You can also view only those projects that you created.

You can now sort the list of projects in Design Center by clicking the column headings.

Options for importing files into a project and downloading a project are now in a new menu that you open by clicking an button on which a gear appears.

Figure 5. The button for opening this menu is in the top-right corner of API Designer, next to the Publish button.

Import files from your computer or from Exchange into folders that are listed in the Files pane of the text editor.

The dialog for publishing API specifications has been simplified.

Figure 6. The new dialog for publishing API specifications is more simple and more helpful.

The dialog for publishing API fragments has also been simplified.

Figure 7. The new dialog for publishing API fragments is also more simple and more helpful.

Within the text editor, you can now set the root file for an API-specification project and for an API-fragment project.

Figure 8. The controls that are related to root files are in the Files pane. This image shows the controls in an API-specification project.

The Import from Exchange dialog is not opened when the option Import from Exchange is selected in an empty API-fragment project.

Fixed a problem that caused the parser to return Unresolved reference error messages in a particular situation.

When a user accessed an API specification that had dependencies that were published in a business group other than the one that the user belonged to, those dependencies were deleted from the specification.

The code examples generated for RAML API specifications in the Documentation pane in the text editor contained errors.

Custom annotations were ignored both in the Documentation pane in the text editor and in Anypoint Exchange.

The Documentation pane in the text editor was showing under the 200 status code the responses for the other status codes for an HTTP method.

The Documentation pane now renders RAML fragments of the types DataTypes, DocumentationItem, and SecurityScheme; complies with Web Content Accessibility Guidelines (WCAG) 2.1; includes new console elements for rendering XML schemas and examples; includes a simpler request panel; renders complex API specifications faster; and includes fixes for several issues reported by customers.

The Filter field in the visual editor did not accept input.

If you are using the text editor to write an API specification in RAML, and you try to edit a file that is a dependency, the message "This file is read-only." appears at the top of the editor. For information about dependencies, see Add a RAML API Fragment to an API-Specification Project as a Dependency.

A number of fixes and styling changes were made to the Documentation pane, which displays the documentation for API specifications and supported RAML fragments, and to the Try It feature, which lets you use the mocking service to simulate calls to resource methods in your specifications.

In the visual editor, errors are now easier to find due to red indicators placed in various locations.

Figure 9. Annotations 1 through 4 show four locations of red indicators that signal the presence of one or more errors. Annotation 5 shows that you can expand the resource body to see the error.

Figure 10. Annotation 1 shows the red border of the section that the error appears in. Annotation 2 points to the field where the error is located.

When you import a specification in a .zip file or import an asset from Exchange into an existing project, the Replace dialog appears when files with the same filename appear in both the .zip file or asset and the project. In this dialog, you can select the files that you want to replace in the project.

The Import dialog now displays a spinner to indicate that the import action is taking place.

It is now easier to include files in a specification. Open the action menu on any file that you want to include and select either the Copy Name or Copy Path options. You can then paste the name or the path into your include statement.

You can clone any file in a project in the text editor. In the Files pane, open a file’s action menu by clicking the three dots to the right of its name. Then, select Clone File. A copy of the file appears in the file list for the project. By default, each copy is named n-name.extension, where n is the next available number, starting from 1. To rename a clone, click the action menu and select Rename.

Users without the Design Center Developer permission could open projects. Now, if a user does not have this permission, the user cannot view the list of projects in Design Center or open a project by visiting the URL.

The Experience API responded with a 403 in a particular case, but a project was still created.

The visual editor displayed an error when a data type was defined as nil and the example used a null value. Several fixes were made to the Undo/Redo feature in the visual editor.

Using the $schema keyword with a custom URI caused the following error: Warning: Unable to load schema from <custom URI>. No schema request service available.

The schemaLocation attribute now loads the location of a referenced XML schema.

The locations of XML schemas to import were not being resolved.

For the fragment types Data Type, Documentation, Extension, Library, Overlay, and Security Scheme, the message Base URI not defined in the API file no longer appears in API Console.

Code samples generated in API Console for resource methods sometimes included errors.

Boolean properties were rendered by API Console as strings in payloads before being passed to the mocking service in method bodies.

Spaces in URI parameters were encoded by API Console as + rather than as %20 in URIs generated by the mocking service.

Large API specifications would not appear in API Console in some cases.

XML-wrapped examples in specifications written in RAML were not parsed correctly in API Console.

A specification written in OAS caused the mocking service to fail with the error `org.json.JSONException: Duplicate key "<name of key>” at…​'.

The content of the summary field in specifications written in OAS did not appear in API Console.

API Console was rendering integers as strings.

When a specification written in OAS had internal references to schema definitions, this message appeared in API Console in the body of the responses for a method: The API file specifies body for this request but it does not specify the data model.

When the mocking service was used for a GET request for which the authorization method was x-clientIDSecret, the message Fill in required parameters appeared even when the Client-id and Client-Secret fields in API Console were filled in.

API Console added tags to XML examples that contained arrays.

The text editor now accepts as valid non-Boolean values for the additionalItems keyword, which is part of JSON Schema.

#%RAML 1.0
title: AMF-VALIDATIONS

types:
  contact: |
    {
      "$schema": "http://json-schema.org/draft-04/schema#",
      "type": "object",
      "description": "Allows the insertion of a Contact Us request into Unilever backend systems",
      "properties": {
        "consumer": {
          "type": "array",
          "items": [
            {
              "type": "number"
            },
            {
              "type": "string"
            },
            {
              "type": "string",
              "enum": ["Street", "Avenue", "Boulevard"]
            },
            {
              "type": "string",
              "enum": ["NW", "NE", "SW", "SE"]
            }
          ],
          "additionalItems":
            {"type": "integer"}
        }
      }
    }

/contact:
  post:
    body:
      application/json:
        type: contact
        example: |
          {
            "consumer": [1600, "Pennsylvania", "Avenue", "NW", 2050]
          }

Fields used in shape merging are now being validated.

#%RAML 1.0
title: test API

resourceTypes:
  rt:
    post:
      body:
        application/json:
          type: object
          properties:
            a1: number

/endpoint:
  type: rt
  post:
    body:
      application/json:
        type: string

Incorrect values specified for enums are now flagged as invalid.

The validation of !include tags is improved. For example, the following example is now parsed as valid because it is considered to be a string payload:

You can now add custom headers when using the mocking service to test endpoints in API specifications that you are developing in the visual editor.

You might experience a delay of a few seconds When you switch between branches of a project in the text editor. Now, a message appears that shows the progress in switching to the selected branch.

In Google Chrome, the text editor displayed no error messages for a project. However, the text editor displayed many error messages for the same project in Mozilla Firefox.

A test request for a file made to the mocking service from a browser correctly resulted in the downloading of the file. However, test requests for the same file made to the mocking service from within API Designer and Exchange did not result in the downloading of the file, even though a status code of 200 was returned.

The error message Error publishing to Exchange: Nout found appeared in the following scenario:

Types defined as nil in payloads are no longer valid.

#%RAML 1.0
title: test

types:
  MyType:
    type: nil
    example: “test”

#%RAML 1.0
title: test

types:
  MyType:
    type: !include schema.json # schema.json is an empty file
    example: “test”

A subtype defining a weaker constraint than one defined by its parent is no longer valid.

#%RAML 1.0
title: test

types:
  MyType1:
    properties:
      name: string
  MyType2:
    type: MyType1
    properties:
      name?: string #invalid

A URI parameter that contains a forward slash (/) is no longer valid.

#%RAML 1.0
title: test

/endpoint:
  uriParameters:
    transaction-Date:
      example: 01/02/2018

Formats for datetime types that do not use "rfc3339" or "rfc2616" are now invalid.

#%RAML 1.0
title: test
types:
  MyType:
    type: datetime
    format: "rfc3338"

The mocking service was switched on for the project before January 10, 2019.

The mocking service has been running continuously since it was switched on.

The button Publish to Exchange is now Publish.

In the visual editor, the top of the Documentation pane now shows the path of the selected resource.

In the Publish to Exchange dialog in previous releases, the version number in the Version field was generated automatically if a specification lacked a version node. Now, if a specification lacks this node, the field remains blank and you must specify a value.

Uploading a library into an API-specification project when using Google Chrome caused Chrome to crash.

The text editor did not recognize the date form "yyy-mm-dd" in JSON example schemas.

Importing a particular API specification into the text editor caused Design Center to become unresponsive in Google Chrome.

The text editor was reporting an internal error during validation, but the reference in the error message was unrelated to the line at which the message stated that the error occurred.

The text editor was incorrectly reporting an unresolved reference for a library type in a resource type.

Very long project names could not be read in various locations.

The text editor displayed random warnings that XSD schemas were invalid in an API specification that had numerous, complex schemas.

You can now see a list of API-specification projects and API-fragment projects that you recently opened or created. In the top-left corner of your browser window, click the three lines to the left of the Design Center logo.

For projects created before January 10, 2019: If no errors appear in your project when the switch that is labeled Show Strict Errors is toggled off, and if errors do appear in your project when that switch is toggled on, a countdown timer appears to the left of the Publish button to remind you of how many days you have left to resolve the errors. If the timer for such a project expires before you have resolved the errors, you will not be able to publish the specification to Exchange until you have done so.

Published copies of complex API specifications in RAML on Exchange were truncated by 20 characters.

API specifications in RAML that included Arabic characters could not be published to Exchange.

JSON examples that included umlauts could not be uploaded to API Designer by means of the Save API.

In some cases, publishing an API specification in RAML to Exchange resulted in the last few characters of the specification not appearing in Exchange.

Importing an asset from Exchange that included dependencies could result in an error message similar to this one: Unexpected token o in JSON at position 1.

An !include in a type definition was incorrectly causing the error message Error while parsing file. at (1,0) to appear.

The API Designer xAPI was truncating the last line from specifications that were uploaded to projects by means of Anypoint CLI.

During attempts to publish an API specification in RAML, the Main file field in the Publish API Specification dialog was blank and the specification could not be published. However, if the specification was imported into a new project, then publishing it to Exchange was possible.

The validation process was erroneously generating the message Recursive type at (0,1) for a particular API specification in RAML.

The fractional-seconds (ff) part of the date-time format yyyy-mm-ddThh:mm:ss[.ff…​] was not supported by the mocking service, which expected the format yyyy-MM-dd’T’HH:mm:ss.

The validation process would erroneously display an Unresolved reference error message for JSON schemas that referenced other JSON schemas by using relative paths.

When you republish a project to Exchange, you now can edit the name only in Exchange. This enhancement prevents naming conflicts. Due to this change, three fields are disabled in the Publish to Exchange dialog when you republish a project: Name, Group ID, and Asset ID.

The Publish to Exchange button is now disabled if your user ID does not have the role either of Exchange Contributor or Exchange Administrator. Disabling the button prevents you from filling in the Publish to Exchange dialog only to receive an error message if your user ID does not have a required role.

Design Center presented a false positive Warning message of different values for the discriminator value.

AMF showed a Warning message of an unused parameter when using the declared uriParameter in a resource type.

In an AMF implementation, using NamedExample inside a NamedExample did not work with Exchange and API Designer.

Design Center allowed the first line in a RAML API definition document to be blank.

The [object Object] error shows up when typing a path to a filename and referencing a directory.

You can now import binary files, such as PDF and PNG files, into your projects. Such files are not parsed and no preview for them is available.

Use behavioral headers with the mocking service to modify in various ways how the mocking service behaves. See Add Behavioral Headers to Simulated API Calls.

Create security schemes for your API specifications. The different supported types are OAuth 1.0, OAuth 2.0, Basic Authentication, Digest Authentication, and Pass Through.

Define union types for elements.

Define enums for strings and numbers.

Specify display names for methods.

Add groups to help you organize assets in the left pane.

When you are using Microsoft Internet Explorer or Microsoft Edge as your browser and you click Design Center or the hamburger menu in the top-left corner as you are using the text editor, there is no longer a browser pop-up asking whether you want to leave the page.

It is now possible to view inline documentation for errors if you are using Microsoft Internet Explorer, Microsoft Edge, or Mozilla Firefox as your browser. Click the information icon that appears next to error messages.

Changes made in the text editor might take up to six minutes to be parsed.

In the text editor, creating a fragment in an API-specification project, leaving the fragment without content, and then adding a reference to it from the main file before adding content to the fragment, caused the reference to be parsed as an error.

Underscores, spaces, and hyphen were not parsed as separator characters in variables in resourceTypes.

It was possible to create API specifications without the appropriate entitlement.

Very long names of API-specification projects are now better supported. If the name of a branch does not appear because the name of a project is too long, you can move your mouse over the path of the branch to see the full path. If the name of a project is too long to be seen all at once in the Publish API Specification to Exchange dialog, you can scroll though the field in which the name appears.

When an API specification included the definition of a type with an !include tag and the example of the type was also included with an !include tag, then the following message appeared: should have required property '<name of property>' at <name of file>.raml

#%RAML 1.0
title: ac-dgt-xcpr

types:
  DigitalProfileCreateRequest:
    type: !include dataType.raml
    examples:
      DigitalProfileCreateRequest_Example: !include example.raml

/profiles:
  post:
    body:
      application/json: DigitalProfileCreateRequest

#%RAML 1.0 DataType
type: object
properties:
  customerProfile:
    type: object
    properties:
      password:
        type: string

#%RAML 1.0 NamedExample
"customerProfile": {
  "password": "abc123"
}

For certain API specifications, the API console was not appearing.

Not all types were being displayed in the list of types in the API console.

When a specification defines a boolean value but does not provide a default value, the API console now provides a default value. Doing so prevents problems from arising with the mocking service.

In some cases, an API-specification project might never finish loading when an attempt was made to open it.

API specifications that included binary files were not displayed properly in Exchange after being published. To ensure that binary files appear properly for API specifications that were created in previous releases of API Designer, follow these steps:

In some cases, references could not be resolved when examples were included. The error message was confusing and gave little information about the cause.

The visual API editor now supports union datatypes and enums.

An information icon now appears after error messages that are related to problems with named examples. Click the icon for a description of such errors and of ways to resolve them.

There is a new dialog that asks you to confirm whether you want to delete a branch.

When a datatype was declared as the union of an object type with an array type, the API editor returned an incorrect parsing error.

When a datatype was declared as a union in the last type entry of a types declaration, the API console did not display the datatype. For example, the datatype unionType that is declared in the specification Test types below would not appear in the API console because it is the last type declared in the list of types.

#%RAML 1.0 DataType
# This file is located at DataTypeA.raml
type: object
additionalProperties: false
properties:
  a:
    type: string

#%RAML 1.0 DataType
# This file is located at DataTypeB.raml
type: object
properties:
  a:
    type: number
  b:
    type: string

#%RAML 1.0
title: Test types

types:
  A:
    type: !include DataTypeA.raml
  B:
    type: !include DataTypeB.raml
  unionType:
    type: A | B

/events:
  /device:
    get:
      body:
        application/json:
          type: unionType

#%RAML 1.0
title: Test types

types:
  A:
    type: !include DataTypeA.raml
  unionType:
    type: A | B
  B:
    type: !include DataTypeB.raml

/events:
  /device:
    get:
      body:
        application/json:
          type: unionType

The title facet was allowed in RAML Library fragments, even though this facet is invalid in fragments of that type.

The Javascript exception Maximum call stack size exceeded was thrown when an API specification contained a recursive datatype reference.

The error message Syntax error, generating empty array at…​ appeared when an array type was included in the declaration of a union type by means of a type expression, as in this example:

#%RAML 1.0
title: Example

types:
  a1:
    type: string[]

/samples:
  post:
    responses:
      200:
        body:
          application/json:
            type: string | a1

Importing an API specification from Exchange would overwrite newer versions of existing assets in a project.

In the visual API editor, it was not possible to drag resources and data types into groups in the left pane of the editor if you were using Microsoft Internet Explorer.

You can now import projects directly from Exchange. You no longer have to download a project from Exchange to your computer or other location, and then import it into a new project in API Designer. See Import Files into an API Project for the steps.

If you define a global media type in a specification in the visual API editor, you no longer are required to select a media type when you define the body of a response for a method. Instead, you can now leave the option default specified. This option is available only if a global media type is defined.

Specifications that were several MB in size could not be published to Exchange. Now, for both the importing of projects from Exchange and the publishing projects to Exchange, the .zip files are reduced in size, preventing such errors.

Resource types and traits in API specifications that were written in RAML 1.0 were not being validated.

A project might never finish loading if you created the project in the visual API editor, created a data type in that project, closed the project, and then attempted to reopen the project.

The API editor returned the error message Recursive type at (x, y) for recursive DataType definitions.

The mocking service would fail if an API specification used the example facet, rather than the examples facet, to include a NamedExample fragment.

The API console might display all examples for all methods that were in a specification, not just the examples for the selected method.

The usability of the feature for forking projects is improved.

The navigation bar at the top of API Designer is now consistent with the navigation bars in other tools within Design Center.

The option API is behind a firewall, which you can toggle on and off by clicking the shield that is on the left side of the toggle for the mocking service, was not functional.

The validation of headers was not occurring when the headers were defined in RAML files that were included as dependencies from Anypoint Exchange.

API Designer did not release a user’s lock on a project branch if the user left the project in the API editor by clicking the hamburger icon (the stack of three horizontal bars) in the top-left corner of the screen. Subsequently, no other user could edit the project branch until the previous user opened the project, opened the branch, and then left the project by clicking Design Center to the right of the hamburger icon.

When you are working on an API fragment, the editor now no longer displays the switch to turn on the mocking service.

When the documentation displayed in the Documentation pane contains more lines than the pane can accommodate, the pane does not display a scrollbar. Therefore, it is not possible to see all of the documentation.

Properties that are defined as numbers in the body of an API appear as strings in the API console.

The mocking service might return a response in JSON, even though the specification defined responses to be in XML.

The mocking service responded with a 400 Bad Request error if a RAML API specification defined a JSON type for an HTTP header.

The editor did not display an error message when a NamedExample fragment contained properties that the RAML specification does not allow.

The behavior of the Import API Example dialog was faulty, making a selection difficult. You can open this dialog when you first create an API-specification project by clicking the word "example" in the sentence "Start project from an existing example," which appears in the left pane of the editor

The mocking service created invalid OAuth redirect URLs.

When the Mocking Service was on, the right pane of the editor was not displaying examples of JSON types for request bodies.

The editor did not show errors when the facet properties was declared twice for a type.

The editor displayed the error message Expecting !!str and !!int provided when numbers were used as keys in type definitions and in named examples.

For type declarations such as the one in this example, the editor displayed an error message that said the example value should be a multiple of the value of the multipleOf key:

The editor displayed the following error message after parsing a RAML project that included an XSD schema: The schema document '<filename>.xsd' cannot include itself

MIME types are now validated as strings, not as regular expressions.

Auto-completion after elements such as uses and !include was not working, and suggestions for content to place after such elements were not being offered.

For projects created before January 10, 2019: You can turn on or off the stricter validation that began with the 2.4.0 release on January 10, 2019. You might want to do so to work with in an API-specification project that was created before this date, but don’t yet have plans for resolving the messages that this validation displays.

The documentation describes additional RAML problems that generate violation and warning messages since the 2.4.0 release.

When a RAML specification uses an example facet was being used, rather than an examples facet, the API editor displays a message. In the previous release, the message was not clear.

Design Center was not using the latest version of the API Console. Therefore, the JSON type for request bodies was not appearing in the right-hand pane of the API editor.

In Firefox, the body of POST and PUT requests was not appearing when the mocking service was being used, preventing requests from being sent correctly.

The API editor (one of the two editors in Design Center’s API Designer) is now using the AMF parser. This parser checks for full conformance with the RAML specification (either 0.8 or 1.0) that is being used for an API specification. If you reopen in the API editor any RAML API specifications that have already been published, you might find that there are instances of stricter validation.

The Design Center now provides native support for OAS 2.0. To learn more, see the documentation.

The names of projects for API specifications and API fragments can now be as long as 64 characters.

The option to download a project in YAML is now replaced with the following options, which you can access by clicking the three dots next to the name of a specification in the left pane:

A problem occurred in which an API specification could not be tested with the mocking service when OAuth 2.0 was used for security. Clicking Authorize and Send after filling in all of the required authentication information merely resulted in the message "Fill in the authorization form first".

The API editor did not detect that an incorrect JSON schema was being referenced.

The API console pane of the API editor was sometimes not being refreshed as different types were being selected. The same problem could occur as different responses were selected.

There were a few formatting problems in the information displayed in the API console pane.

Swedish characters were not supported in the Crowd release (November 2017).

If a RAML API specification contained a DataType that extended another DataType, the information shown in the API console pane about the extending DataType could sometimes be incorrect.

The API editor could take too long to resolve one or more DataType resources. During that time, the API console pane was blank.

When a RAML extension extended a file that used a library that was itself defined in a fragment, and the library included a trait with the !include tag, the API editor was unable to locate the trait.

If a RAML API fragment defined multiple properties as <propertyName>: string | nil, the API console pane did not display any information, or did so only after a long delay, after the API specification that referenced the fragment was opened.

If a project included a JSON schema, and that file itself included another JSON schema, Design Center failed to load the second schema.

The API editor was requiring the media type to be declared for message bodies, even though the RAML specifications state that mediaType is optional for body nodes.

If you tried to import a Swagger 2.0 JSON file that contained an array of objects, Design Center threw a parsing error.

The mocking service was not presenting a choice of authentication methods when a basic securityScheme was being referenced from a library RAML fragment.

It was possible for projects imported into Anypoint Studio from the API editor in Design Studio to contain RAML errors that were not pointed out by the API editor.

RAML errors not reported by the API editor could cause problems in the API console pane, such as failures to display various pieces of information.

If a uses node specified an invalid path to a library, the API editor displayed this unhelpful message:

Cannot read property 'ast' of null at (1, 0)

The API editor was allowing a blank line as the first line in RAML files.

For very large API specifications, validation and the appearance of the API Console in the API editor could require much more time than usual.

If an endpoint were simply /, the API editor would throw a parsing error.

In the API console of the API editor, query parameters did not appear after you clicked the Try It button.

In the API editor, changing the version number of an API specification that you were publishing to Exchange would change the value of all instances of the "version" keyword in the specification. Only the value for the root instance should have been changed.

When a custom datatype was declared as Int64, the range declared for the datatype was not validated. For example, the mistake in this definition — declaring a maximum value that is too high for Int64 values — was not caught:

my_int64:
  type: integer
  format: int64
  minimum: 1000000000000000000
  maximum: 9999999999999999999

Using double angle brackets (double chevrons) enclose a parameter name in resource type and trait definitions was not supported in the API editor.

Some valid regular expressions in the RAML "pattern" element were unsupported in the API editor.

In some cases, publishing an API specification to Exchange from the API editor would result in the content of the API specification being reordered incorrectly in the editor.

OAS files with identical names were allowed to be imported. There was no check to find out whether existing OAS 2.0 files in a project already had the same name as an OAS 2.0 file being imported.

The protocols node was not being validated either in the text editor or in the visual editor.

Error messages were not appearing for invalid examples nodes. Here is an example of an invalid examples node:

Uploading an API-specification project by using anypoint-cli resulted in the following message if the project contained a large number of files:

Importing an OAS 2.0 file that used parentheses in its name resulted in an error, but the error message did not explain the problem well.

The conversion of an OAS 2.0 file to RAML, which takes place when an OAS file is imported, resulted in the required field in the properties of response objects being set to false even when the value in the OAS file was true.

Attempts to import either RAML files or OAS 2.0 files via URL failed. If you tried to import a RAML file via URL, the file appeared empty in the text editor. If you tried to import an OAS 2.0 file via URL, the Import dialog would display the error message Invalid OAS document.

When switched on, the mocking service could incorrectly insert the URI to the mocking server.

It was possible to import an example into an API-specification project that was in read-only mode.

If in the text editor you clicked the plus sign in the left sidebar, selected Other in the Add New File dialog, and then clicked Create without specifying a name for the file, a new file with the name */ appeared in the file list. It was not possible to delete that file.

The left sidebar of the editor now lists groups, their resources, and their datatypes.

An example API to use in the visual editor is now available from a link in the left sidebar.