Contact Free trial Login

API Designer (Crowd) Release Notes

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

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.

Information About Version 2 and How to Migrate

For information about the new features in Version 2 of the mocking service and about how to migrate your projects, see Migrate API-Specification Projects to Version 2 of the Mocking Service.

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 code editor did not recognize the date form "yyy-mm-dd" in JSON example schemas.

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

  • The code 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 code 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 code 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. See Modify Published RAML API Specifications to Conform Completely to RAML 0.8 or 1.0 for an explanation of why projects created before January 10, 2019 must meet this requirement.

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 Code 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 code 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 code editor might take up to six minutes to be parsed.

  • In the code 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. For more information about what to do in such cases, see Modify Published RAML API Specifications to Conform Completely to RAML 0.8 or 1.0.

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

We use cookies to make interactions with our websites and services easy and meaningful, to better understand how they are used and to tailor advertising. You can read more and make your cookie choices here. By continuing to use this site you are giving us your consent to do this.