API Designer (Crowd) Release Notes

These release notes cover the following versions of API Designer (Crowd):

2.35.0

October 16, 2021

Improved Specification Validation in the Text Editor

  • 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.

Fixed Issues

Issue ID

The Publish to Exchange dialog now prevents publishing a project with an invalid root file name.

DESIGNER-6885

API Designer now enforces a 50MB limit when performing an Import from File.

DESIGNER-6900

AMF now correctly validates arrays of types in JSON schemas.

SE-22204

2.34.2

September 30, 2021

Fixed Issues

Issue ID

Publishing to Exchange while the root file resides in a folder no longer results in the following error:

Cannot publish with invalid root file name

SE-22876

2.34.1

September 27, 2021

Fixed Issues

Issue ID

API Designer no longer repeatedly displays the following when creating or switching branches:

This branch has changed externally

SE-22744

2.34.0

September 18, 2021

Improved Specification Validation in the Text Editor

  • 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"
        ]
    }

Autocompletion Improvements

  • Inner document path suggestions no longer contain a trailing slash.

Fixed Issues

Issue ID

API Designer no longer incorrectly validates empty oneOf schemas that contain the required keyword.

SE-21827, SE-21981, SE-22242

Content is no longer deleted after changing a file extension (via the Rename option) within the text editor.

DESIGNER-6664

Importing files with names containing invalid characters (such as ,) is now correctly allowed.

DESIGNER-6667

2.33.0

August 21, 2021

Improved Specification Validation in the Text Editor

  • 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"

    An error is now displayed:

    Error: Duplicated property names: duplicate

Autocompletion Improvements

  • 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.

Fixed Issues

  • 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.

    Previously, unknown error was returned.

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

  • RAML 1.0 inline unions in extensions now parse correctly.

    For example, given the following specification and extension:

    #%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

    The unionDate property parsed as the first declared type (in this case a datetime-only). However, given the inverse union, only nil values were validated. This resulted in an error:

    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'

2.32.0

July 24, 2021

Improved Specification Validation in the Text Editor

  • 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 Improvements

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

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

Fixed Issues

  • Enum values declared in an array type were not displayed in 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.

2.31.0

June 26, 2021

Improved Specification Validation in the Text Editor

  • 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.

    For example, previously "effectiveDate": "22021-06-05T00:00:00" would not return an error. It now returns a 400 Bad Request error.

Autocompletion Improvements

Autocompletion now:

  • 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.

Fixed Issues

  • 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.

2.30.0

June 8, 2021

Improved Specification Validation in the Text Editor

  • 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

Fixed Issues

  • 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
                  }
                ]
              }
            },

    The Documentation section incorrectly displayed the following:

    item.companyType
    Any

2.29.0

May 1, 2021

Improved Specification Validation in the Text Editor

  • 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

Fixed Issues

  • 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.

2.28.0

April 3, 2021

Improvements in the Validation of Specifications by the Text Editor

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

    For example, the following RAML defines two types (AnimalWithPaws and AnimalWithHoofs), and a union of these two types called Animal:

    #%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

    The type Animal is now considered valid.

Fixed Issues

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

    The following message now displays, advising you to add the parameter:

    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 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.

    For example, renaming person[] to user in the following RAML resulted in a new symbol named user instead of user[].

    #%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.

2.27.0

March 6, 2021

New Features

  • The API Designer text editor now supports the following actions:

    • Find locations where a definition is referenced.

    • Select code ranges.

    • Navigate to a symbol.

    • Extract an element to a declaration.

    For more information, see Helpful Features in the Text Editor.

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

Fixed Issues

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

    For example, under API Summary in the visual editor, specifying application/json and switching to the text editor resulted in the following invalid code:

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

    The following error was reported:

    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

    The Edit spec option no longer displays in READ ONLY VIEW if the project was previously deleted in Design Center.

  • 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.

    Now, the duplicate file is ignored and not imported.

Known Issues

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

    For example, the following snippet contains a type: number value that is 16 digits:

    16digits:
      type: number
      maximum: 9999999999999999

    Design Center incorrectly displays Max value: 10000000000000000.

    The current type system does not support the required precision.

2.26.0

February 6, 2021

Fixed Issues

  • 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.

    Now the root level folder is removed and its content is imported into the root folder of the new 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.

2.25.0

January 7, 2021

Improvements in the Validation of Specifications by 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.

    For example, the following demonstrates JSON with syntax errors:

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

    Prior to AMF version 4.5.1, the following was displayed:

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

    In AMF version 4.5.1, additional information is now displayed:

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

Fixed Issues

  • 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.

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

2.24.0

December 12, 2020

Improvements in the Validation of Specifications by the Text Editor

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

This release of API Designer provides support for AML Modeling Framework (AMF) version 4.5.0. In this version of AMF the severity of validation for required boolean facet properties was downgraded from violation to warning. Although it throws a warning, in any JSON Schema specification draft this field is still parsed and set correctly in the model.

The following example shows an incorrect usage:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "additionalProperties": false,
  "properties": {
    "property1": {
      "type": "string",
      "required": true
    }
  }
}

This example returns the error: Required property boolean value is only supported in JSON Schema draft-3. MuleSoft recommends not using this approach.

Fixed Issues

  • 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.

Known Issues

  • 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.

2.23.0

November 14, 2020

New Features

  • Added new dialogs for creating an API specifications and fragments.

    You can more easily create new API specifications and fragments from an existing file or project. Supported file types are JSON, RAML and YAML. You can also use an existing project saved as a ZIP file. This feature also enables you to create a new Mule application from a JAR file.

  • 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 Issues

  • 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.

2.22.0

October 29, 2020

Improvements in the Validation of Specifications by the Text Editor

  • RAML Unions

    Fixed issue where incorrect validations were occuring under specific conditions using unions. For example, the following API is now valid:

    #%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

    Added validation for missing version definitions for the baseUri. For example, the following API is now valid:

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

Fixed Issues

  • 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.

2.21.0

September 19, 2020

New Features

Fixed Issues

  • 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.

    Here is an example of this tag used in an API specification, and that the text editor flags 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.

    For example, in this API specification, the scope used is USER:

    #%RAML 1.0
    title: API
    
    securitySchemes:
      oauth_2_0: !include securitySchemes/oauth_2_0.raml
    
    /users:
      get:
        securedBy: [ oauth_2_0: { scopes: [ USER ] } ]

    However, in this SecurityScheme fragment, the scheme is defined with the scope ADMIN:

    #%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 ]

    In previous releases, the text editor would have allowed the use of the USER scope in the API specification.

2.20.1

September 1, 2020

This release fixes this issue:

The text editor prevented users from typing in invalid characters when naming a new branch. However, in previous releases it was possible for users to paste names that contained invalid characters into the Create branch field and create branches with those names. Now, the text editor automatically removes invalid characters that are pasted into the Create branch field.

2.20.0

August 22, 2020

This release includes a new feature and an enhancement. It also fixes one issue and includes improvements to how API specifications are validated by the text editor.

New Feature

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

    To see all of the locations in a file where an object is used, click the cursor in the name of the object where that object is declared.

    For example, the type person is declared on line 5 at the first callout in the following example API specification. That type is subsequently used on line 16 at the second callout. If you click person on line 5, the text editor highlights person on line 16.

    #%RAML 1.0
    title: Test Highlighting
    
    types:
      person:  (1)
        type: object
        properties:
          name: string
    
    /test:
      get:
        responses:
          200:
            body:
              application/json:
                type: person  (2)

    This highlighting works for all declarable objects, such as types, security schemes, resource types, and traits.

    Highlighting appears only where the object is used, not every location where its name appears. For example, in the following example API specification, person is declared as a type on line 5 at callout 1, mentioned on line 14 at callout 2, and used on line 17 at callout 3. When you click in person at callout 1, person is highlighted only at callout 3.

    #%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)

Enhancement

The button highlighted by default in the Replace File? dialog is now Keep Both rather than Replace.

Fixed Issue

When validation of any XML instance against any type declaration cannot be performed, the following warning message is now displayed:

Warning: Could not validate XML.

Improvements in the Validation of Specifications by the Text Editor

Two improvements were made in the validation of API specifications written in OAS. One improvement was made in the validation of API specifications written in RAML 1.0.

OAS

  • Cyclic references between files are now supported for API specifications that are written in OAS.

    For example, the following API specification is now considered valid:

    swagger: '2.0'
    info:
      title: pet api
      version: 1.0
    definitions:
      pet:
        type: object
        properties:
          animalRef:
            $ref: 'ref.yaml#/definitions/animal'
    paths: {}
    definitions:
      animal:
        type: object
        properties:
          petRef:
            $ref: 'api.yaml#/definitions/pet'
  • Unresolved Reference error messages no longer appear for valid specifications.

    For example, in releases prior to version 2.20.0, the text editor returned the error message Unresolved reference `TestSchema for an API specification like the following:

    swagger: "2.0"
    info:
      title: 'test'
      version: "1.2"
    
    paths:
      /pets:
        get:
          produces:
          - application/json
          responses:
            '403':
              $ref: 'ref.yaml#/responses/response1'
    definitions:
      TestSchema:
        type: string
    
    responses:
      response1:
        description: 'test'
        schema:
          $ref: '#/definitions/TestSchema'

RAML 1.0

Error messages no longer appear for valid examples inside of overlays.

For example, the following API specification is now considered valid:

#%RAML 1.0
title: Test

types:
  TestEntity:
    type: object
    properties:
      id: string
#%RAML 1.0 Overlay
title: Overlay
extends: ./api.raml

types:
  TestEntity:
    example: |
      {
        "id": "t123"
      }

2.19.0

July 25, 2020

New Feature

You can duplicate projects in API Designer. You might want to duplicate a project if you need to make extensive changes to the project without losing the original on which the duplicate project is based. For more information, see Duplicate a Project.

Enhancements

  • 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 previous releases, the text editor reported dependencies as missing when projects entered read-only mode.

Fixed Issues

  • 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.

    Such files were imported, but they could not be accessed in the text editor.

Improvements in the Validation of Specifications by the Text Editor

OAS 3.0

Invalid recursive references are not detected. For example, the following OAS 3.0 API specification is now invalid:

{
  "openapi": "3.0.0",
  "info": {
    "version": "0.0.1",
    "title": "test"
  },
  "paths": {
    "/path": {
      "post": {
        "responses": {
          "400": {
            "description": "desc",
            "content": {
              "application/json": {
                "schema": {
                  "$ref": "#/components/schemas/mytype"
                }
              }
            }
          }
        }
      }
    }
  },
  "components": {
    "schemas": {
      "mytype": {
        "$ref": "#/components/schemas/mytype"
      }
    }
  }
}

RAML 1.0

If you do not define scopes in an OAuth 2.0 security schema, you can use any scope in the implementation of your API. For example, the following specification is now valid:

#%RAML 1.0
title: GitHub API
securitySchemes:
  oauth_2_0:
    description: This API supports OAuth 2.0 for authenticating all API requests.
    type: OAuth 2.0
    settings:
      accessTokenUri:   https://someurl/oauth2/access_token
      authorizationGrants: [ client_credentials ]
/users:
  get:
    securedBy: [ oauth_2_0: { scopes: [ USER ] } ]

2.18.0

June 27, 2020

This release includes new features and fixes issues.

New Features

  • Limited support for OAS 3.0

  • Changes to the documentation panel in API Designer:

    The right panel in the text editor of API Designer, which displays the documentation that is written into API specifications and enables you to make requests to the mocking service, includes these changes:

    • Support for features that are specific to OAS 3.0

    • Support for OAS flows for OAuth 2.0

      For information about OAS flows, see the page "OAuth 2.0" on swagger.io at https://swagger.io/docs/specification/authentication/oauth2/.

    • Support for applying multiple security definitions simultaneously in requests made to the mocking service

    • Support for disabling automatic encoding of URI parameters in requests to the mocking service

      Use the new no-auto-encoding annotation, as in this example:

      paramName:
        (no-auto-encoding):
          type: string
  • New "go to" actions in the text editor

    In RAML API specifications, you can:

    • Right-click the name of a type and select Go to Definition in the pop-up menu to navigate to the declaration of the type.

    • Right-click the name of a resource type or trait and then select one of these options in the pop-up menu:

      • Select Go to Definition to navigate to the declaration for the resource type or trait.

      • Select Go to Type Definition to navigate to the definition of the resource type or trait.

    • Right-click a resourceTypes or traits node and select Go to Implementations to see where the resource types or traits that are defined in the node are implemented.

    • Right-click the declaration of a Type and Annotation Type that uses a library, and then select one of these options from the pop-up menu:

      • Select Go to Definition to navigate to the corresponding definition.

      • Select Go to Type Definition to navigate to the corresponding type definition.

    In OAS API specifications, you can:

    • Right-click an example of a reference object and select Go to Definition in the pop-up menu to navigate to the definition of that object.

    • Right-click a reference to a schema file (for example, schema.yaml in $ref:"schema.yaml") and select Go to Definition to navigate to the file.

    • Right-click the name of an embedded schema in a reference to a schema file (for example, Contact in $ref:"schema.yaml#/definitions/Contact") and select Go to Definition to navigate to that portion of the schema.

Fixed Issues

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

    The error message was Missing header x-user-id.

  • 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.

Improvement in the Validation of API Specifications

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

    For example, the following API is now valid:

swagger: '2.0'
info:
  title: Sample API
  version: ''
paths:
  /resource:
    get:
      responses:
        '200':
          description: ''
          schema:
            $ref: 'f/complexType.yaml'
  /resource2:
    get:
      responses:
        '200':
          description: ''
          schema:
            $ref: 'f/baseType.yaml'
type: object
properties:
  ref:
    $ref: baseType.yaml
type: object
properties:
  name:
    type: string

2.17.2

June 2, 2020

This release fixes these issues:

  • Suggestions and errors were not displayed for an API specification written in RAML 1.0 and that should have generated the error message "Error recursive shape".

  • The text editor allowed an API specifiction written in RAML 1.0 to be published to Anypoint Exchange, even though the specification contained an error.

  • The search field in the text editor lost focus whenever a character was typed in it.

  • At times, the Documentation panel did not display any content.

  • At times, clicking a link to an unreferenced file from within the Project Errors view caused the browser window to become blank.

2.17.0

May 30, 2020

This release includes new features and fixes several issues.

New Feature

  • 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.

    You can view the errors and warnings for all files in a project, or the errors and warnings for the file that is currently displayed in the editor. This new view also lists all unreferenced files in the current project.

    When you first open the text editor in this release, a dialog appears that describes the features of the new view and displays screenshots.

  • 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.

Fixed Issues

  • 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.

Improvement in the Validation of API Specifications

The text editor now validates recursive shapes correctly. For example, the following OAS 2.0 API specification is considered valid:

{
  "swagger": "2.0",
  "info": {
    "title": "test",
    "version": "1.1"
  },
  "definitions": {
    "Causes": {
      "$ref": "#/definitions/Test"
    },
    "Test": {
      "properties": {
        "subsenses": {
          "items": {
            "$ref": "#/definitions/Test"
          },
          "minItems": 1,
          "type": "array"
        }
      },
      "type": "object"
    }
  },
  "paths": {}
}

However, the following RAML 1.0 API specification is considered invalid:

#%RAML 1.0
title: Recursive
types:
  Recursive:
    type: object
    properties:
      myP:
        type: Recursive
/recursiveType:
  post:
    responses:
      201:
        body:
          application/json:
            type: Recursive

Known Issue

The URL for the mocking service might remain visible even after the mocking service is switched off. To hide the URL, switch to another page in the Documentation pane.

2.16.0

May 2, 2020

This release includes three enhancements and four fixes. It also includes an improvement in how the text editor validates API specifications that are written in OAS 2.0.

Enhancements

  • 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 message shows a Discard and Use New Changes button. You must click the button to accept the changes. Because the text editor automatically saves often, you will usually lose only a few changes.

  • 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:

    1. Click the name of the dependency.

    2. Select Change version.

    3. Select the current version in the Change version dialog.

  • 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:

    • An icon of a lock now appears next to the exchange.json file to indicate that this file is read-only.

    • The names of all of the files in this folder are now in gray to indicate that they should not be edited.

Fixed Issues

  • 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.

Improvement in the Validation of Specifications by the Text Editor

In API specifications written in OAS 2.0, references to YAML files are now supported. For example, the following API specification is now considered valid:

root.yaml
swagger: "2.0"
info:
  version: 1.0.0
  title: Swagger Petstore
paths:
  /pets:
    get:
      responses:
        "200":
          description: unexpected error
          schema:
            $ref: 'ref.yaml'
ref.yaml
type: object
required:
  - code
  - message
properties:
  code:
    type: integer
    format: int32
  message:
    type: string

2.15.0

April 4, 2020

This release includes several new features, two enhancements, several fixes, and several improvements to how the text editor validates specifications.

New Features

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

    The equivalent field on the left side of the visual editor can help you locate security schemes, resources, and data types faster.

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

    An imported specification completely replaces the specification that is currently open in the visual editor. You can import a specification only if it does not contain any fragments.

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

    • If the shield is selected, the request won’t be proxied. For example, request URLs that the mocking service provides look like this: https://anypoint.mulesoft.com/mocking/api/v1/links/<mocking-ID>/<endpoint>

      Selected
      Figure 1. The shield is selected.
    • If the shield is not selected, the request will be proxied. For example, request URLs that the mocking service provides look like this: https://anypoint.mulesoft.com/apiconsoleproxy/api/v1/proxy/https://<hostname>/mocking/api/v1/links/<mocking-ID>/<endpoint>

      Not selected
      Figure 2. The shield is not selected.

Enhancements

  • 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.

Fixed Issues

  • 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.

Improvements in the Validation of Specifications by the Text Editor

One improvement was made for the validation of specifications written in RAML. Three were made for the validation of specifications written in OAS 2.0.

RAML

Declarations of status codes as optional are now flagged as invalid. For example, the definition of the response 201 in the following specification causes the text editor to display the error message Status code for a response must be a value between 100 and 599 at (x, y):

#%RAML 1.0
title: test

types:
  x-ratelimit-limit:
    type: number
    description: The rate limit ceiling for this endpoint.

traits:
  rateLimited:
    responses:
      201?:
        headers:
          x-ratelimit-limit: x-ratelimit-limit

/test:
  get:
    is: [rateLimited]
    responses:
      200:

OAS 2.0

  • Duplicate body parameters are now parsed as invalid.

    For example, the following specification causes the text editor to display the error message Cannot declare more than one 'body' parameter for a request or a resource at (x, y).

{
    "swagger": "2.0",
    "info": {
        "title": "Test",
        "version": "1.0.0"
    },
    "paths": {
        "/": {
            "parameters": [
                {
                    "name": "body parameter 1",
                    "in": "body",
                    "schema": {}
                },
                {
                    "name": "body parameter 2",
                    "in": "body",
                    "schema": {}
                }
            ],
            "get": {
                "responses": {
                    "200": {
                        "description": "ok"
                    }
                }
            }
        }
    }
}
  • The value of a security requirement object now must be an array.

    For example, the text editor flags this specification as invalid because the value of Bearer is set to a string:

{
  "swagger" : "2.0",
  "info" : {
    "title" : "Registry",
    "version" : "1"
  },
  "paths" : {
  },
  "security" : [ {
    "Bearer" : ""
  } ],
  "securityDefinitions" : {
    "Bearer" : {
      "in" : "header",
      "name" : "Authorization",
      "type" : "apiKey"
    }
  }
}

To correct the problem, set the value to an array:

{
  "swagger" : "2.0",
  "info" : {
    "title" : "Registry",
    "version" : "2"
  },
  "paths" : {
  },
  "security" : [ {
    "Bearer" : []
  } ],
  "securityDefinitions" : {
    "Bearer" : {
      "in" : "header",
      "name" : "Authorization",
      "type" : "apiKey"
    }
  }
}
  • The name facet is now required.

    For example, the following specification causes the text editor to display the message Name is mandatory in License object at (x, y):

{
 "swagger": "2.0",
 "info": {
   "title": "Testing API",
   "version": "1.0.0",
   "license": {}
 },
 "paths": {}
 }

2.14.2

March 11, 2020

This release includes the following two fixes: * The visual editor displayed the Publish with unreferenced files? confirmation dialog during the publish process. This dialog is relevant only for projects created in the text editor. * The text editor displayed the error message Not found when a file for which the name contained invalid characters was selected.

2.14.1

March 7, 2020

This release includes one enhancement, seven fixes, and four improvements to how API specifications are validated.

Enhancement

  • 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.

    However, you can select an option to override this default and to include unreferenced files in a published project.

    The dialog with the option
    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.

Fixed Issues

  • 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.

    Example of the first case
    ---
    swagger: "2.0"
    info:
      description: This API is written in OAS 2.0.
      version: "1.0"
      title: api-in-oas
    Example of the second case
    %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".

    Now, if you try to name such a project "exchange", the name given to the project is "1-exchange".

  • 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.

    The firewall icon also appeared for all types of RAML fragment, rather than only for Overlay and Extension fragments.

Improvements in the Validation of Specifications by the Text Editor

Improved Validation of the required Field in JSON Schemas

If you are using JSON Schema 4 or later (the text editor uses version 4 if you do not specify a version), the required field takes an array as its value. In previous versions of JSON Schema, this facet took a boolean value.

In previous releases of API Designer, the text editor did not display an error message if you were using JSON Schema 4 or later and you used a boolean value for the required field. Now, the text editor displays this error message:

'required' field has to be an array at (<x>,<y>)

For example, the text editor no longer considers valid the use of the required field in this specification:

#%RAML 0.8
title: amf-validations

/jobs:
  displayName: Jobs
  post:
    description: Create a Job
    body:
      application/json:
        schema: |
          {
            "$schema": "http://json-schema.org/draft-04/schema",
            "properties": {
                "input": {
                    "type": "string"
                }
            },
            "required": "true",
            "type": "object"
          }

Validation of the type Field in Parameters in OAS 2.0 API Specifications

In previous releases, the text editor did not display an error message when the list of parameters for an endpoint in an OAS 2.0 API specification lacked a type field. Now, the text editor displays this message:

Cannot find valid schema for parameter at (<x>,<y>)

For example, the text editor no longer considers valid the lack of the type field in this specification:

{
  "swagger": "2.0",
  "info": {
    "title": "amf-validations",
    "version": "v1"
  },
  "host": "api.github.com",
  "schemes": [
    "https"
  ],
  "paths": {
    "/users": {
      "get": {
        "description": "Get a list of users",
        "parameters": [
          {
            "name": "page",
            "description": "Specify the page that you want to retrieve",
            "required": true,
            "in": "query"
          }
        ]
      }
    }
  }
}

Validation of the Definitions of Properties in JSON Schemas

In previous releases, the definitions of properties in JSON schemas were not validated. For example, the text editor no longer considers valid the definition of the property in this specification, which contains an array instead of an object:

#%RAML 0.8
title: amf-validations

/media:
  displayName: Most Popular Media
  get:
    description: Get a list of what media is most popular at the moment.
    responses:
      200:
        body:
          application/json:
            schema: |
              {
                "$schema": "http://json-schema.org/draft-03/schema",
                "type": "object",
                "properties": [
                  {
                    "date": "date"
                  },
                  {
                    "amount": "integer"
                  }
                ]
              }

Validation of JSON Schemas That Do Not Define Types

In previous releases, if an example of a property for which no type was defined used any type other than object, the text editor incorrectly displayed this error message:

<property> should be object at (<x>,<y>)

For example, the text editor would display the error message for this specification because the definition of the property from does not include a definition of the property’s type. The example, however, shows that the type is string:

#%RAML 1.0
title: amf-validations
types:
  Client:
    type: |
      {
        "$schema": "http://json-schema.org/draft-03/schema",
        "type": "object",
        "properties": {
          "from": {
            "required": true
          }
        }
      }
    example:
      {
        "from": "test"
      }

2.13.3

February 13, 2020

This release fixes two issues.

  • Clicking the Upgrade button in the notice about upgrading the mocking service resulted in the error message Connection lost.

  • The browser window in which the text editor in API Designer was being used would sometimes go blank.

2.13.0

February 6, 2020

New Features

  • 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.

    The filter dialog
    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.
    1 The button for opening the filter dialog.
    2 The filter for specifying or selecting the type of project to list.
    3 The filter for selecting the range of time during which projects that you want to list were last updated.
    4 The checkbox for selecting only the 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.

    Two new project-level options also appear on that menu: Rename and Delete.

    The new project menu
    Figure 5. The button for opening this menu is in the top-right corner of API Designer, next to the Publish button.
    1 The menu includes two sections. This section includes the options for importing files and downloading the project.
    2 This section includes the options for renaming the project and deleting it.
    3 This is the button that you click to open the menu.
  • Import files from your computer or from Exchange into folders that are listed in the Files pane of the text editor.

    Click the three dots to the right of the name of a folder and select either Import or Import from Exchange.

Enhancements

  • The dialog for publishing API specifications has been simplified.

    A comparison of the previous publish dialog with the new one.
    Figure 6. The new dialog for publishing API specifications is more simple and more helpful.
    1 The name of the API specification appears as the title of the dialog.
    2 There are now only two fields that require values.
    3 An option to add the API specification to API Manager is included in the More options section.
    4 Help for deciding on an asset version number appears within the dialog.
    5 Links to additional help are provided.

    To learn more about publishing an API specification, see Publish an API Specification.

  • The dialog for publishing API fragments has also been simplified.

    A comparison of the previous publish dialog with the new one.
    Figure 7. The new dialog for publishing API fragments is also more simple and more helpful.
    1 The name of the API specification appears as the title of the dialog.
    2 There is now only one field that requires a value.
    3 Help for deciding on an asset version number appears within the dialog.
    4 A link to additional help is provided.

    To learn more about publishing an API specification, see Create and Publish an API Fragment.

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

    In the previous release, you set the root file in the Main file field of the publishing dialog.

    The controls related to root files
    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.
    1 The menu opened by clicking the three dots to the right of a specification includes the option Set as root file.
    2 An indicator shows which specification is currently set as the root file.
    3 Click the question mark in the menu to learn more about root files. The question mark opens this topic in the online documentation: Root Files in Projects in the Text Editor in API Designer.

Fixed Issues

  • 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.

    Now, when the user opens a project, if the specification any has dependencies that were removed from Exchange or if the project was published in a different business group, API Designer takes the following actions:

    • Displays a message in the Dependencies pane to warn of the missing dependencies.

    • Diables the options "Show in files," "Change version," and "Open in Exchange" for each missing dependency.

    • Disallows publishing the API specification to Anypoint Exchange.

  • 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.

Improvement in the Validation of Specifications by the Text Editor

In previous releases, the text editor displayed an error message similar to this one when a specification included a repeat facet in an API specification written in RAML 0.8: Property 'repeat' not supported in a RAML 1.0 string node at (13, 13). The parser incorrectly validated the facet against the RAML 1.0 specification, which does not define this facet.

Now, the parser correctly validates RAML 0.8 API specifications that use the repeat facet, such as this specification, and does not display an error message:

#%RAML 0.8
title: Test API

securitySchemes:
  - oauth_2_0:
      description: |
        Supports OAuth 2.0 for authenticating all API requests.
      type: OAuth 2.0
      describedBy:
        headers:
          Authorization:
            type: string
            repeat: true

/users:
  get:
    securedBy: [ oauth_2_0 ]

2.12.0

January 11, 2020

This release includes seven enhancements, twenty fixes, and three improvements to how API specifications are validated.

Enhancements

  • 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.

    For example, an error in a response body for a resource method is indicated in red in four locations:

    apid vapid resource error 1
    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.

    Annotation 1 points to the first red indicator: the name of the type of resource method. Annotation 2 points to the second red indicator: the name of the resource method. Annotation 3 points to the third red indicator: the response code. Annotation 4 points to the fourth red indicator: the border of the Bodies (1) section.

    Annotation 5 points to the arrow you can click to expand the Bodies (1) section to see the error. When you click it, the border expands (as shown by Annotation 1 in the next image) and red borders appear on the left and right of the field where the error is located.

    apid vapid resource error 2
    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.

    Hover over the field for a message that explains the error.

    The same types of indicator appear for errors in other parts of a specification. In this next example, the error is in the definition of the definition of a property of a data type. The name of the data type appears in red, the left border of the Property Name section is red, and you can click the arrow icon to expand this section and see the error.

    apid datatype error 1
  • 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.

    With the 2.10.0 release, this dialog includes the new option Select all, which lets you select all of the listed files.

  • 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.

Fixed Issues

  • 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.

Improvements in the Validation of Specifications by the Text Editor

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

    According to JSON Schema (https://json-schema.org/understanding-json-schema/reference/array.html#tuple-validation), the additionalItems keyword "controls whether it’s valid to have additional items in the array beyond what is defined in items."

    For example, the text editor no longer displays an error message that says the use non-Boolean values for the instance of additionalItems in this schema is invalid:

    #%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.

    For example, the following lines will be no longer valid in a RAML specification:

    #%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

    In this example, an attempt is being made to merge an object, defined as rt under resourceTypes and that has a number property, into a scalar. The definition of the endpoint defines its payload type as an rt object. However, the definition of the endpoint then tries to set the type of the payload to string, which is incompatible with the definition of the rt object as being of type number.

  • Incorrect values specified for enums are now flagged as invalid.

    For example, the value for this enum would be flagged as invalid because it is a map with a key and a value, rather than just a value:

{
  "swagger": "2.0",
  "info": {
    "title": "My API with Types",
    "version": "1.0"
  },
  "paths": {
    "/orgs": {
      "get": {
        "responses": {
          "200": {
            "description": "",
            "schema": {
              "type": "string",
              "enum": [{
                  "key": "value"
              }]
            }
          }
        },
        "security": []
      }
    }
  }
}

The correct declaration would be this:

{
  "swagger": "2.0",
  "info": {
    "title": "My API with Types",
    "version": "1.0"
  },
  "paths": {
    "/orgs": {
      "get": {
        "responses": {
          "200": {
            "description": "",
            "schema": {
              "type": "string",
              "enum": [
                "value",
                "value1"
              ]
            }
          }
        },
        "security": []
      }
    }
  }
}
  • 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:

#%RAML 1.0
title: test API

/resource:
  get:
    responses:
      200:
        body:
          application/json:
            example: !includedexample

2.9.0

October 4, 2019

This release includes two new features, an enhancement, and several fixes.

Also, four more types of errors are flagged as invalid by the parser that was released on January 10 of this year. The parser that API Designer used before that date did not flag these errors as invalid.

New Features

  • 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.

Enhancement

  • 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.

Fixed Issues

  • 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:

    1. Create an API-specification project in the text editor.

    2. Go to the Dependencies panel and consume one or more Exchange assets.

    3. Close the project.

    4. Go to Exchange and delete one of the two consumed assets.

    5. Return to API Designer and reopen the project.

    6. Try to publish the API specification to Exchange.

Errors Now Flagged As Invalid

  • Types defined as nil in payloads are no longer valid.

    Example 1

    In this example, the value of type must be string, not nil:

    #%RAML 1.0
    title: test
    
    types:
      MyType:
        type: nil
        example: “test”

    Example 2

    In this example, the JSON schema must define MyType as a string type. However, the schema is empty.

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

    The error message in cases like this is should be null at …​.

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

    In this example, the subtype MyType2 has the optional property name, defined as a string, even though the parent type MyType1 already defines its name property as required.

    #%RAML 1.0
    title: test
    
    types:
      MyType1:
        properties:
          name: string
      MyType2:
        type: MyType1
        properties:
          name?: string #invalid

    The error message in cases like this is Resolution error: sub type has a weaker constraint for minItems than base type for minItems.

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

    In this example, the example for the URI parameter transaction-Date would cause the parser to display an error message.

    #%RAML 1.0
    title: test
    
    /endpoint:
      uriParameters:
        transaction-Date:
          example: 01/02/2018

    The error message in cases like this is Value '01/02/2018' of uri parameter must not contain '/' character.

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

    The following example would cause the parser to display an error message.

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

    The error message in cases like this is Invalid format value for datetime, must be ‘rfc3339’ or ‘rfc2616’.

2.8.3

September 19, 2019

This release fixes the following issue: In the 2.8.0 release, an Unresolved reference error was reported for a resource type that was in fact free of errors.

2.8.0

September 7, 2019

Announcement

Version 2 of the mocking service is replacing Version 1. You must migrate any API-specification project that meets both of these conditions:

  • 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.

Dates for the Deprecation and End of Life of Version 1

  • On November 29, 2019, Version 1 of the mocking service will be deprecated. Starting on that date, third-party tools must include this header in requests that they send to the mocking service to test endpoints in API specifications being developed in API Designer:

    x-deprecation-acknowledgement

    The header must have this value:

    I understand that version 1 of the mocking service is deprecated and that I need to upgrade before February 1, 2020.

  • Starting February 1, 2020, Version 1 of the mocking service will no longer send responses to requests. If you have not migrated your projects to use Version 2 of the mocking service by this date, the mocking service will return the HTTP status code 301 and provide a link to this document.

New Feature

The new behavioral header MS2-Status-Code-Selection gives you two options for controlling how the mocking service selects a status code for responses to requests. See Add Behavioral Headers to Simulated API Calls for details.

Enhancements

  • The button Publish to Exchange is now Publish.

    It opens a small message that contains the button Publish to Exchange. The message explains why you might want to publish a specification or fragment to Exchange. If a spec or fragment has already been published, the message contains a link to it on Exchange.

  • 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.

Fixed Issues

  • 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.

2.7.0

August 10, 2019

This release introduces two new features and fixes several issues.

New Features

  • 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.

Fixed Issues

  • 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.

2.6.0

July 13, 2019

This release introduces two enhancements and fixes several issues.

Enhancements

  • 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.

Fixed Issues

  • 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.

2.5.0

June 15, 2019

This release introduces several new features in the visual editor.

New Features in the Text Editor

  • 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.

New Features in the Visual Editor

  • 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.

    In previous releases, you could select only one data type at a time for properties, bodies, payloads, headers, and any other kind of element. Now, you can choose multiple data types to create union data types for any of those elements.

    When creating a union type, you won’t be able to edit any custom properties of the union type itself. An instance of the data type should meet all restrictions of at least one of the super types.

  • Define enums for strings and numbers.

  • Specify display names for methods.

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

Enhancements

  • 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.

Fixed Issues

  • 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

    Here are examples of an API specification, a data type, and an example that would produce this error:

    API specification
    #%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
    Data type
    #%RAML 1.0 DataType
    type: object
    properties:
      customerProfile:
        type: object
        properties:
          password:
            type: string
    Example
    #%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:

    1. Delete the binary file from your API-specification project.

    2. Import the binary file again into your project.

    3. Publish the specification to Exchange again, making sure to increment the version number.

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

2.4.8

May 18, 2019

This release introduces three new features and an enhancement, and it fixes several issues. There is also one known issue.

New Features

  • 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.

Enhancement

The dialog for creating projects in API Designer has been redesigned for a simpler experience.

Fixed Issues

  • 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

    However, if you moved the declaration of unionType (as in the example below), then unionType would appear in the API console.

    #%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.

    These steps reproduced the problem:

    1. Create a RAML fragment and publish it as version 1.0.0 to Exchange.

    2. Create a RAML API specification, import the fragment, and publish the API specification to Exchange.

    3. Open the RAML fragment created in step 1, edit it, and publish it as version 1.0.1.

    4. Create a new project and RAML API specification, import version 1.0.1 of the fragment.

    5. In the project, import from Exchange the RAML API specification created in step 2.

    The version of the RAML fragment that is being used in the project is now 1.0.0, rather than 1.0.1.

  • 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.

Known Issue

If you are not using Google Chrome or Mozilla Firefox as your web browser when using the API editor, clicking an information icon that appears next to an error message does not open a window to display information about the error.

2.4.6

April 20, 2019

This release includes two new features and several fixes. There is also one known issue.

New Features

  • 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.

Fixed Issues

  • 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.

Known Issue

Because of a bug in a third-party library that is used for the validation of XML against an XSD schema, the API editor can be inconsistent in displaying the error message Could not validate XSD schema. For example, you might or might not see the error message whenever you open a particular file that contains XML.

2.4.5

April 6, 2019

This release includes a new feature, two enhancements, and two fixes.

New Feature

The editor now caches validations that are made by the AMF parser. (This parser was released on January 10 this year in the 2.4.0 release. See the release notes for 2.4.0 for more details about it.) Every time a file was opened in previous releases, the AMF parser would validate the file; during the validation, the API console would not appear in the right-hand pane of the editor. Now, opening a file does not cause the AMF parser to validate it. Therefore, the API console appears immediately whenever you switch to another file in a project. Any change to a project — typing, importing a file, or other actions — clears the project’s cache and triggers the AMF parser to validate the project again.

Enhancements

  • 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.

Fixed Issues

  • 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.

2.4.4

March 23, 2019

This release fixes six issues.

Fixed Issues

  • 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.

2.4.3

February 23, 2019

This release fixes two issues.

Fixed Issues

  • 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.

2.4.2

February 9, 2019

This release fixes a number of issues.

Fixed Issues

  • 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:

#%RAML 1.0 DataType
displayName: exampleType
type: number
multipleOf: 0.01
example: 19.99
  • 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.

2.4.1

January 25, 2019

This release includes enhancements and fixes a number of issues.

Enhancements

  • 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.

    To turn this validation off, toggle the switch that is labeled Show Strict Errors in the top-right corner of the editor. The default is On. + Even if you toggle this validation off, the grace period in which you must resolve the messages is still in effect. The grace period lasts at least until January 10, 2020.

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

Fixed Issues

  • 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.

2.4.0

January 10, 2019

This release includes several enhancements and fixes a number of issues.

Enhancement

  • 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 AMF parser is at version 2.0.0.

  • 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:

    • Download as: Downloads a RAML specification as an OAS specification, or an OAS specification as a RAML specification.

      The downloaded file is not guaranteed to be a correct specification.

    • Convert: Converts a RAML specification to an OAS specification, or an OAS specification to a RAML specification.

      The converted file is not guaranteed to be a correct specification.

Fixed Issues

  • 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 message has been improved.

  • 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.

2.2.9

August 9, 2018

This release contains an enhancement.

Enhancement

If your organization contains more than one group ID, you can now select the group ID to associate an API specification with when you publish that specification to Anypoint Exchange.

2.2.8

July 26, 2018

This release introduces a change and fixes for several issues.

Enhancement

The text editor now supports the following structure for the declaration of a baseUri in specifications that are written in RAML 1.0:

baseUri:
  value: http://www.example.com/api

Fixed Issues

  • 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:

title: New API

types:
  ids:
    type: object
    properties:
      identification:
        type: string
        examples:
          - MuleSoft
          - Salesforce

The correct way to define this examples node would be as follows:

title: New API

types:
  ids:
    type: object
    properties:
      identification:
        type: string
        examples:
          id1: MuleSoft
          id2: Salesforce

The symbol -, which is used incorrectly in the invalid examples node is used for defining elements in arrays, as in this example:

title: New API

types:
  ids:
    type: object
    properties:
      identification:
        type: array
        examples:
          id1:
            - MuleSoft
            - Salesforce
          id2:
            - Mule
            - CRM
  • Uploading an API-specification project by using anypoint-cli resulted in the following message if the project contained a large number of files:

    Error: Could not open JPA EntityManager for transaction; nested exception is javax.persistence.PersistenceException: org.hibernate.exception.JDBCConnectionException: Could not open connection

  • 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.

2.2.7

May 16, 2018

This release fixes these issues:

  • Supplying a base URI parameter in the visual editor, using the parameter in a base URI, closing the visual editor, and then reopening the project resulted in an error message and a blank middle panel.

  • Selecting the type Number for a new Data Type in the visual editor, specifying a format, and changing the type to Integer resulted in the RAML viewer still including the specified number format.

  • In the visual editor, changing the type for a base URI parameter caused the RAML viewer to show the new type, but the Type field continued to show the previously selected type.

2.2.6

April 20, 2018

This release fixes these issues:

  • Attempts to import OAS JSON files would result in this error message being displayed: Cannot read property 'hasOwnProperty' of null Such files could also fail to be converted by the JSON-to-RAML online conversion tool.

  • Some warning and error messages were not being displayed.

2.2.5

April 6, 2018

This release includes two enhancements and fixes an issue.

Enhancements

  • 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.

Fixed Issue

The word "type" could not be used as the name of a property in a RAML API specification.

Was this article helpful?

💙 Thanks for your feedback!