Flex Gateway新着情報
Governance新着情報
Monitoring API ManagerThese release notes cover the following versions of API Designer (Crowd):
September 28, 2024
You can now see the dependencies and rulesets options button without having to expand the Dependencies panel.
August 27, 2024
Issue Resolution | ID |
---|---|
You can now share projects with a team without getting an |
W-16570967 |
August 17, 2024
Certain dependencies are updated to improve security when authorizing the GitHub Application.
API Designer now supports the AML Modeling Framework (AMF) 5.5.4.
Issue Resolution | ID |
---|---|
You now see |
W-16254309 |
You now see the examples in the documentation pane when including RAML library data types in API Specifications. |
W-14798477 |
July 20, 2024
You now see a 500 status code error when the dependency resolver fails.
You no longer see an error when selecting a Github project if you’re not synced to GitHub. You can open the project in read-only mode instead.
June 24, 2024
You now receive a notification if the project size is likely to affect performance.
You now see a login message when your session expires.
Note: Some new features may not be available immediately as they are being activated progressively for clients.
API Designer now supports AsyncAPI 2.6.
To learn about the AsyncAPI journey, see AsyncAPI Support to Implement Event-Driven Architecture.
May 25, 2024
You can now successfully see the Design Center project list after navigating through settings.
April 27, 2024
You can now see text with links highlighted in the Publish to Exchange modal.
You can now click the version link on the Publish to Exchange modal to be successfully redirected to your asset.
April 6, 2024
API Designer now supports the AML Modeling Framework (AMF) 5.4.9.
Issue Resolution | ID |
---|---|
You can now put spaces in the search bar of the Share project modal and get the correct results. |
W-15191959 |
You now see the correct error message when referencing a non-existent response object in an API fragment. |
W-15570769 |
March 2, 2024
Media types now show in alphabetical order in API Designer Visual mode.
The horizontal scroll bar is now hidden when there are no errors to show on the Project Errors panel.
You now need to enter a valid asset ID to publish an API specification to Exchange.
Validation of Governance rulesets is improved. If you enable manual validation mode, you now see a No conformance issues to show after validation
message on the Project Errors panel after successful validation.+
If the validation fails, you can copy the details of the error to your clipboard to see the non-validating ruleset.
Issue Resolution | ID |
---|---|
You can now see examples in the API Console when defining |
W-14855586 |
Now only the |
W-14616485 / W-14234271 |
Now only the |
W-14616485 / W-14234271 |
Files are now re-fetched after publishing specifications to Exchange to improve performance. |
W-14616485 / W-14234271 |
February 3, 2024
You can now see the correct language badge tag on the Rulesets
and Import from Exchange
modals.
You can now use paste options on API Designer.
You can now scroll to see all your files on the Replace file
modal.
The Filter by project name field now resets when switching organizations.
Issue Resolution | ID |
---|---|
You can now see examples in the API Console when defining |
W-14249741 |
You can now see examples in the API Console when providing them under properties with XML attributes. |
W-14615657 |
You can now see examples in the API console when defining |
W-14572757 |
You now see an authentication required message when you don’t have permission to access a project or your session has expired. |
W-14674994 |
Performance is improved on API specifications. |
W-14557131 / W-14236380 |
January 6, 2024
Now, when switching between the API Projects and the Shared with me tabs on the Design Center home page, the project name input field resets.
December 9, 2023
You can now filter files by .
or +
characters.
Project owners and organization administrators can now transfer their ownership to a different organization member. For more information, see Design Center Permissions.
API Designer now supports the AML Modeling Framework (AMF) 5.4.5.
You can now narrow int64
base types to int62
base types without getting an invalid type inheritance base type
error message.
Issue Resolution | ID |
---|---|
Your API now shows the correct header name when defining header parameters. |
W-14438988 |
You can now see examples in the correct format when defining XSD schema examples. |
W-12623953 |
You can now convert your API from OAS YAML to JSON without having some query parameters under the |
W-13976753 |
You can now see validation issues in the Publishing to Exchange modal when trying to publish an API. |
W-14399162 |
You can now reference existing components in API Fragments without getting a |
W-14380118 |
You can now reference |
W-13759080 |
You can successfully access synced with Github projects with more than 30 branches. |
W-14408711 |
You can successfully open RAML specifications without getting error messages. |
W-14445080 |
November 11, 2023
You can now change the version of your dependencies without removing them from your project.
You can now delete one version of your dependency to remove all versions from your project.
The project limit reached
dialog is improved to facilitate the use of assistant technologies such as screen readers.
You can now delete a project directly from the Design Center home page.
You can now disable auto-validation of Governance rulesets to run a single validation for each ruleset rather than triggering multiple automatic validations that can exhaust your resources. For more information, see Improving Ruleset Validation.
You now get suggestions for !include
tags in RAML specifications and $ref
properties in Async APIs.
API Designer now supports the AML Modeling Framework (AMF) 5.4.4.
You now get a message specifying we don’t support XML 1.1 when referencing a XML 1.1 file.
Issue Resolution | ID |
---|---|
You can now publish complex API specifications without getting an error message. |
W-14251387 / W-14216791 |
You can now successfully see the conformance issues of your projects. |
W-14210545 |
You can now include XSD files as data-type for a request in an API specification without getting a |
W-14202641 |
You can now successfully publish to Exchange without delays. |
W-14094069 |
September 30, 2023
API project exchange.json
files are now displayed in pretty print format when you create new projects.
API Designer now supports the AML Modeling Framework (AMF) 5.4.2-4.
You can now parse a union of three or more members that are not nested under a different union.
Issue Resolution | ID |
---|---|
You can now define child properties without having them display the mandatory fields of the parent property in the API Console. |
W-13770031 |
You can now define reference a RAML library without getting a |
W-14109695 |
You can now publish RAML libraries without getting a |
W-14074325 |
You can now publish a RAML specification without getting a |
W-14105863 |
You now see a |
W-13217899 |
September 1, 2023
Issue Resolution | ID |
---|---|
You can now create connectors to use with Flow Designer and Anypoint Studio, and publish those to exchange, without getting an email with the |
W-13794149 |
You can now define examples with union type properties without getting a |
W-13820034 |
August 19, 2023
Issue Resolution | ID |
---|---|
You can now use multiple Oauth 2.0 properties when parsing OAS 3.0 APIs without getting a |
W-13723448 |
You can now see the examples in the API console when defining multiple response examples. |
W-13609146 |
You can now see query parameters defined as a union correctly listed in the API console. |
W-13580768 |
You can now properly see error messages in the API console. |
W-13260699 |
July 22, 2023
Issue Resolution | ID |
---|---|
You can now see XSD schema content types in the API Console. |
W-13195361 |
You can now use |
W-13062033 |
Performance improvements are implemented when validating large APIs before publishing to Exchange. |
W-13280705 |
June 24, 2023
Issue Resolution | ID |
---|---|
You can now see a list of errors as soon as you add a new ruleset, or open a project with existent rulesets. |
W-12707967 |
May 29, 2023
API Designer now supports new audit logs. For more information, see Audit Logging.
API Designer now supports the AML Modeling Framework (AMF) 5.3.0.
You now see the correct error message when using different formats for two examples of the same type.
Issue Resolution | ID |
---|---|
When the OAS API spec schema is not defined, it now defaults to |
W-12592278 |
You now see the information typed in kafka bindings displayed on the API Console for AsyncAPI specifications. |
W-12528269 |
April 29, 2023
API Designer now supports the AML Modeling Framework (AMF) 5.2.6.
You now see an error message when using a JSON schema with type inheritance
properties.
Issue Resolution | ID |
---|---|
You can now successfully generate an access token from the API Console. |
W-12065711 |
April 1, 2023
You can now select API fragments with the same name when selecting API fragments in the Dependencies modal.
You are now redirected to the documentation page when clicking Help with Sharing API projects on the share dialog.
You can now disable the API Designer GitHub Integration. For more information, see Disabling the GitHub Integration.
API Designer now supports the AML Modeling Framework (AMF) 5.2.5.
You now see an error message when a RAML type is invalid. (For example, in
properties:
products []
you now see [] is not a valid type
)
Design Center now validates that the property type and the discriminatorValue
field are the same.
Issue resolution | ID |
---|---|
You can now see exactly where the error is when validating union types with an empty array in a RAML 1.0 specification. |
W-12513290 |
You can now see an error message in the API Console when building a request with a question mark as a header. |
W-12371572 |
You can now properly publish a new version of an existing asset to exchange. |
W-12359794 |
March 20, 2023
API Designer and Design Center fonts are updated to improve legibility, localization, and site performance.
March 4, 2023
You now get a confirmation message when removing a fragment from the Exchange Dependencies panel.
When you open an API specification created in Visual mode through the Exchange portal, it opens in the Visual editor as Read only mode.
API Designer now supports the AML Modeling Framework (AMF) 5.2.4.
Issue resolution | ID |
---|---|
You no longer get an incorrect error when defining examples in parameters and headers. Note that the Required Examples version must be updated to 1.0.3. |
W-12205009 |
You can now see where exactly the error is when defining examples in parameters and headers. |
W-12059358 |
You can now see the correct information in the API Console when defining |
W-12163469 |
You can now see all properties in the console when defining |
W-12138301 |
You can now see the correct information in the API Console when defining |
W-12080342 |
The API console now shows the endpoint details when opening an API fragment project. |
W-12266057 |
February 4, 2023
You can now set the API version directly from the code when publishing API specifications in OAS 2 or OAS 3.
You can now edit the example area in Visual API Designer mode without losing your place on the page.
You can now use the Chance access button with the keyboard.
When defining an ExternalFragments
property in a OAS specification, it now links to the referenced node properly.
You can now create API Fragments in RAML, OAS 3.0, and JSON Schema format. For more information, see Create and Publish an API Fragment in the Text Editor in API Designer
Studio does not support OAS 3.0 fragments. |
API Designer now supports the AML Modeling Framework (AMF) 5.2.3.
Issue resolution | ID |
---|---|
You no longer get incorrect API conformance errors when defining the 204 status code in the response. Note that the Anypoint Best Practices version must be updated to 1.5.1 |
W-12447219 |
January 21, 2023
API Designer displays an error message when you publish an asset with invalid values in the Business Group ID
, Asset ID
, or Asset name
fields in the Publishing to Exchange dialog.
You can now see the correct information when clicking the Exchange tab on the sidebar in the read-only asset page.
You can now use control + F
to search for strings in a project with errors without crashing the browser.
The exchange tab is no longer visible when viewing code from Exchange.
The Design Center User Interface is updated for better accessibility.
New Design Center Business Group and Project Level permissions are added for more granularity when sharing projects. For more information see Design Center Permissions.
API Designer now supports the AML Modeling Framework (AMF) 5.2.2.
Issue resolution | ID |
---|---|
The example data field is now null in the API Designer documentation when a string property is defined with the nullable field set to |
W-11323805 |
You can now use the |
W-12019663 |
The API console now shows the correct data when using the |
W-12039245 |
You can now convert a RAML 1.0 API specification to OAS 3.0 when defining a union type with null values. |
W-12099989 |
December 15, 2022
Fixed resolution | ID |
---|---|
You can now open a published project from the Exchange portal with API Designer without getting an error message. |
W-12040250, W-12218977, W-12284772 |
December 10, 2022
November 12, 2022
When creating an API Spec in the Visual editor mode, you can now successfully delete and add new content in the Example area of a data type.
You can now navigate through the Filter menu of a project with your keyboard.
You can now properly see the values defined for enum
types in the Query parameters section in the summary page of the API documentation.
You can now successfully generate a request URL with a defined path parameter.
When defining AnnotationType
and properties
in RAML, you no longer get incorrect suggestions.
When suggesting boolean fields in OAS2, you no longer get incorrect suggestions that add double quotes.
API Designer now provides support for AML Modeling Framework (AMF) 5.2.0.
You no longer get validation errors when defining additional properties.
Fixed resolution | ID |
---|---|
You can now succesfully preview DataType documentation when using |
W-11848788 |
You can now use a root |
W-11689045 |
Now, in the summary page of the API documentation, you see the object name as |
W-11866516 |
October 29, 2022
Added a security layer to the API console, so that only registered domains are reachable.
For more information, see the Allowlisting Trusted Domains documentation.
You now get an email notification when your API fails conformance to rulesets your organizations validates.
For more information, see the Adding Dependencies to an API-Specification Project documentation.
Issue | ID |
---|---|
When publishing an API specification from API Designer to Exchange, the version field is now pre-populated according to what you define in the API spec. For more information, see the Publishing API Specifications documentation. |
W-11705888 |
October 15, 2022
You can now edit the API Version field when publishing a project to exchange.
The Publish button is updated for better accessibility, and a new Exchange tab is added to the sidebar.
You can now use special characters when renaming branches on projects synced to GitHub.
You can now have multiple response status codes on API Visual Designer.
API Designer now supports AML Modeling Framework (AMF) version 5.1.0.
Issue | ID |
---|---|
You can now successfully preview documentation for DataType fragment files. |
W-11649355 |
You no longer get incorrect API Governance conformance errors when adding an API fragment as a dependency. |
W-11587420 |
You can now successfully refer to API fragments without getting conformance errors. |
W-11460246 |
You can now properly use the |
W-11091661 |
September 13, 2022
When defining multiple keys in an OAS 3 spec, they now show the correct documentation and labels associated with those fields.
When entering the Try It panel, the Client ID field no longer shows an error message, and the warning messages are fully and correctly displayed
You can now click on Clone, Edit, and Delete using assistant technologies.
You can now see a visual indicator of the keyboard focus when navigating through API Specification fragments.
You can now enter values for query parameters without losing focus.
You can now extract the body of your project to a new data type without getting an error message.
You can now navigate through UI elements with the keyboard.
When using the securedBy
and SecuredByCompletionPlugin
fields with RAML files, you no longer get incorrect suggestions.
When using API annotations that generate a YAML Map, you will now be suggested to include a break line at the end instead of an empty space.
Issue | ID |
---|---|
The customer header is now displayed correctly when enabled. |
W-11407528 |
You now get an error message when creating invalid RAML (union types with enums) definitions. |
W-11381880 |
When designing an API specification using OAS 3.0, you no longer get a duplicated resource path error message. |
W-11295643 |
August 20, 2022
You can now navigate through the Exchange Dependencies panel using assistant technologies such as screen readers.
When clicking View Code on a published exchange asset related to a no longer existing branch, you no longer receive an error message.
When clicking View Code on a published exchange asset, you no longer receive an error message.
When renaming your branches with a $
character, you no longer receive an error message.
When renaming or cloning a project, you now need to enter a name before confirming.
Design Center now includes links to our Github Synchronization documentation page.
You now have more granularity in API Designer permissions.
All user interface components have been updated to APID Components v3.
Issue | ID |
---|---|
You can now click Authorize to successfully connect your Github account with Design Center. |
W-11585264 |
You can now use API Governance rules without getting an error message. |
W-11225118 |
Namespaces and tags are now successfully displayed when added on examples for content-type application/XML schema. |
W-11077505 |
The Datagraph Admin permission can’t be used to download Design Center projects anymore. |
W-11253041 |
July 23, 2022
You can now see suggestions under the uses
property in a library fragment when defining data type properties in RAML Data Type fragments files.
API Designer now supports AML Modeling Framework (AMF) version 5.0.10.
When you use $ref
in OAS Parameter Specifications, you no longer receive an error message.
Issue | ID |
---|---|
You can now edit a branch from exchange without having its content overwritten with other branches. |
W-11378789 |
You can now successfully filter by Project Type. |
W-11429747 |
You can now define the root file for Async projects imported from Github. |
W-11279542 |
API designer now successfully deletes a branch after a merge. |
W-11253255 |
API designer now creates the correct documentation for an AsyncAPI when using multiple messages. |
W-11091661 |
Governance conformance issues are no longer shown in the Functional tab. |
W-11316515 |
When you view code from Exchange in the text editor, you no longer receive a 'No zip file for gav' error. |
W-11316441 |
June 25, 2022
When using the expander toggle (>
) on the Errors panel, you now expand the item you selected instead of multiple items.
When you click Cancel on a create dialog, you no longer receive an error message.
You can now navigate through create menus without losing focus.
GitHub Synchronization is a version control tool that maintains API specifications existing in several locations. Use GitHub Synchronization to enable two-way synchronization between API Designer and your GitHub repository.
For more information, see the Github Synchronization documentation.
You can now re-name the main branch in adherence to our Inclusive Product Language Program.
You can now see suggestions when defining data type properties in RAML Data Type fragments files.
API Designer now supports AML Modeling Framework (AMF) version 5.0.9.
All AML Dialect JSON Schema integer
types are now converted into long
types to support larger numbers.
Issue | ID |
---|---|
You can now add a new response on a resource instead of replacing the existing one while using the visual editor. |
W-11262351 |
May 28, 2022
User interface terminology and navigation have been updated for better accessibility.
The text editor sidebar and editor shelf expander toggles (>
and <
) are no longer overlapped with other elements.
When you view code from Exchange in the text editor, you no longer receive a 'No zip file for gav' error.
The visual editor UI now validates the resource name field and disallows entry of invalid characters such as double quotes ("), carat (^), and percent (%).
You can now successfully import an example from the visual editor.
API Designer now supports AML Modeling Framework (AMF) version 5.0.8.
In OAS3 APIs with references to endpoints that have references to schemas, second-level references with valid paths are resolved properly.
When you convert a RAML API to OAS 2.0 and mediaType
is defined for an endpoint, the text editor uses the endpoint’s mediaType
rather than the default.
Issue | ID |
---|---|
API Designer now properly renders markdown files in the documentation view. |
W-10647692 |
The mocking service now properly renders examples and schemas in OAS 3.0 APIs when you use |
W-10888940 |
The error that the schema must not import, include, or redefine itself no longer occurs when you import RAML API specifications. |
W-10685149 |
April 30, 2022
A new ruleset dependency type is introduced in this release to enable you to validate your API specifications against rulesets cataloged in Exchange.
For more information, see the API Governance documentation.
API Designer now supports AML Modeling Framework (AMF) version 5.0.6.
When you declare a security scheme in a RAML library, use it in an API specification, and then convert the RAML specification to OAS, the OAS specification is now generated with valid security scheme information.
When you define both date and pattern formats for OAS types, API Designer shows a warning that the pattern property might be ignored if the date format already defines a standard pattern.
Issue | ID |
---|---|
The property of data type |
W-10899011 |
Due to an enhancement in the way absolute paths are parsed, if you apply a governance ruleset dependency to a project in API Designer, absolute file paths are no longer allowed in fragment dependencies for that project. If this enhancement impacts your project, you can either update and republish the fragments or switch back to the prior behavior and opt not to apply rulesets to that project. For details, see this KB article.
April 2, 2022
Boolean schemas are now parsed for JSON schema draft-06.
Security scheme fragments with media type defined at the global level are now validated properly.
Code suggestions are now properly shown for OAS 3.0 specifications that use externalDocs
regardless of the position of the cursor.
The hover text is now properly shown for OAS 3.0 specifications that use externalDocs
.
Issue | ID |
---|---|
The file import now properly validates file names regardless of how the files are imported. |
SE-24042 |
March 5, 2022
You can now select lifecycle states when publishing API specifications to Exchange. For more information, see Publish an API Specification.
February 5, 2022
Issue | ID |
---|---|
Tests of OAS v3 endpoints can now be executed. |
SE-23274 |
When errors are found in included files, the editor now indicates errors in the root file as well as in the included files. |
DESIGNER-7123 |
January 8, 2022
API Designer now provides support for AML Modeling Framework (AMF) 5.0.2.
OAS 3.0 specification properties with nullable fields set to true
are now correctly validated when sent in payloads.
Issue | ID |
---|---|
The |
SE-23167 |
In the visual editor, selecting an The |
DESIGNER-2821 |
In the visual editor, a |
DESIGNER-4705 |
In OAS 3.0 specifications, 'responses' node autocomplete suggestions no longer include the New Response
option.
In RAML 1.0 specifications, autocomplete suggestions now correctly show for objects inside array
types.
In RAML 1.0 specifications, autocomplete now correctly shows prefix suggestions.
In RAML 1.0 specifications, autocomplete no longer suggests duplicates for resourceTypes
and traits
.
December 11, 2021
API Designer now provides support for AML Modeling Framework (AMF) 5.0.1.
AMF parser validations no longer incorrectly highlight the origin of the document. Validations now highlight the correct line of the validated shape or fragment.
Issue | ID |
---|---|
External schemas referenced in an API specification no longer introduce unexpected |
SE-22292 |
Selected resources and methods now correctly show in the Description field in the visual editor. |
SE-22991 |
URI parameter data types imported from libraries no longer return validation errors. |
SE-23076 |
When using Mozilla Firefox, the |
SE-23195 |
November 13, 2021
When you initiate the import of a ZIP file but do not choose a file, the Import button is no longer enabled.
The tooltip for a deprecated dependency is now displayed correctly.
API Designer now provides support for AML Modeling Framework (AMF) 5.0.0.
Issue | ID |
---|---|
When a branch is changed externally and you click Discard and Use New Changes, the window no longer remains open with the |
DESIGNER-6835 |
API Designer now supports relative references from one XSD schema to another. If you create an API specification that contains an XSD schema that references another XSD schema, the import no longer fails with the warning For example, you can now include an import line such as |
SE-22684 |
October 16, 2021
You can now create, import, and edit AsyncAPI specifications in API Designer. See Event-Driven API (AsyncAPI) Support Release Notes.
API Designer now provides support for AML Modeling Framework (AMF) 4.7.8.
Inheriting from array types no longer results in an Incompatible types [array, array]
validation error.
Including a disjoint UnionShape
within the examples
node of a schema no longer results in an expected type: X, found: Y
error.
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 |
September 30, 2021
Issue | ID |
---|---|
Publishing to Exchange while the root file resides in a folder no longer results in the following error:
|
SE-22876 |
September 27, 2021
Issue | ID |
---|---|
API Designer no longer repeatedly displays the following when creating or switching branches:
|
SE-22744 |
September 18, 2021
API Designer now provides support for AML Modeling Framework (AMF) 4.7.7.
The union
and nil
types are now parsed with equivalence.
Validation no longer fails for required facets in properties containing the nillable
shorthand type. For example, the following code no longer results in Error: Property 'required' not supported in a RAML 1.0 string node
:
#%RAML 1.0 title: APIMF-2975 types: Test: properties: name: required: false type: string?
AMF now saves properties declared in required
but not present in properties
. For example, the following code no longer results in an ignored address
property:
{ "$schema": "http://json-schema.org/draft-04/schema#", "type" : "object", "properties": { "name": {"type": "string"}, "age": {"type": "integer"} }, "additionalProperties": false, "required": [ "address" ] }
Inner document path suggestions no longer contain a trailing slash.
Issue | ID |
---|---|
API Designer no longer incorrectly validates empty |
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 |
DESIGNER-6667 |
August 21, 2021
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 in OAS specifications containing parameters
tags now suggests "info" (instead of "in") for root nodes.
Autocompletion in OAS specifications is now correct for version
tags when subsequent text exists.
The time to open the Publish to Exchange dialog is improved for projects containing several files and dependencies.
The XML 'name' property was ignored in the example XML payload generated via API Console.
Opening a project occasionally resulted in a non-completing Loading…
message. The browser console displayed the following error:
Uncaught DOMException: Failed to execute 'importScripts' on 'WorkerGlobalScope'
When publishing assets to Exchange takes more than 1 minute, the following message is now displayed:
Error publishing to Exchange: Request timed out due to project size. Asset may have been successfully published. Please verify in Exchange.
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'
July 24, 2021
API Designer now provides support for AML Modeling Framework (AMF) 4.7.5.
OAS 2.0 security scheme definitions that do not contain name
and in
required fields now result in warnings:
Warning: Property 'in' is required in a OAS 2.0 apiKey node
Warning: Property 'name' is required in a OAS 2.0 apiKey node
Autocompletion now displays correct options for example
nodes that include example fragment files.
Autocompletion now displays correct RAML method names for endpoint name nodes.
Enum values declared in an array type were not displayed in the Documentation panel.
When publishing to Exchange, API projects with a large number of files intermittently resulted in the following HTTP 502 timeout error response:
Error publishing to Exchange: Unknown error
In API Console, selecting a body content type of application/xml
created an invalid payload. The following error was displayed:
400 Bad Request
It was not possible to scroll through large amounts of Exchange dependencies.
API Console displayed a validation error when entering fractional numbers as query parameters.
June 26, 2021
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 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.
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.
June 8, 2021
API Designer now provides support for AML Modeling Framework (AMF) 4.7.3-1.
Invalid discriminator mapping values now result in a warning. For example, the invalid
value in the last line of the following snippet results in Warning: Unresolved reference 'null'
.
openapi: "3.0.0" info: version: 1.0.0 title: 1-api paths: {} components: schemas: Dog: type: string Cat: type: string Animal: oneOf: - $ref: '#/components/schemas/Dog' - $ref: '#/components/schemas/Cat' discriminator: propertyName: petType mapping: invalid: 'null'
In RAML 0.8, specifying a relative reference (for example, !include common/400.example
) instead of the intended absolute reference (for example, !include /common/400.example
) results in an error:
Error: Resource common/400.example not found
The parser now resolves spaces in values with !include
tags, such as the following:
title: !include /title file.yaml
Schemas with schemaLocation
values containing .xsd
files resulted in the following incorrect warnings:
Unreferenced file: This file is not referenced by the root file
Incorrect strings replaced the response section title in the Responses section. The title text is now displayed as Example in all cases.
OAS specification 'description' and 'example' values did not display in the Documentation section.
Mocking service requests did not successfully complete due to certain missing JSON headers.
API Console did not display the correct property type for arrays declared with the []
qualifier (for example, string[]
).
API Console did not display the correct information for schema definitions containing the anyOf
keyword, such as in the following snippet:
"companyType": { "anyOf": [ { "type": "string", "maxLength": 10, "description": "The legal name of the given company.", "enum": [ "EU" ] }, { "type": "string", "description": "Any future added type", "maxLength": 10 } ] } },
The Documentation section incorrectly displayed the following:
item.companyType
Any
May 1, 2021
API Designer now provides support for AML Modeling Framework (AMF) 4.7.2.
RAML nillable shorthand string?
types were not recognized in uriParameters
, queryParameters
, or headers
maps. The following error was displayed:
Cannot declare unresolved parameter
Previously published Exchange dependencies failed to load in API Designer when importing an API specification or fragment and creating branches containing /
(for example, features/mybranch
).
For some projects in the project list, the Created By
field displayed UUIDs instead of names.
The mocking service returned an Invalid Schema
error after correcting ref
paths in an .xsd
schema file.
April 3, 2021
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.
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 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.
March 6, 2021
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.
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.
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.
February 6, 2021
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.
January 7, 2021
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 ','
Errors were not being reported when publishing malformed OAS assets to Anypoint Exchange.
Moving files into renamed directories caused the following error:
<filename> is not a valid directory
The Documentation panel’s Operation ID URL did not match the selected server after loading an OAS 3.0 specification.
Specifications that did not define baseUri
resulted in no endpoint URL documentation.
December 12, 2020
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 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.
November 14, 2020
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 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.
October 29, 2020
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 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.
September 19, 2020
You can have multiple files open simultaneously in API Designer’s text editor.
Each file can be open in its own tab. For details, see Edit in Multiple Tabs in the Text Editor.
Using only one action, you can rename declarable objects everywhere they are used in a project that is open in the text editor.
For details, see Helpful Features in the Text Editor.
When multiple media types were declared in a response body, the documentation pane sometimes did not list them all.
When multiple responses were declared for an API specification written in OAS 2.0, the documentation pane sometimes did not display all of the example responses.
The properties accessTokenUri
and authorizationTokenUri
in settings
nodes were not validated in OAuth 2.0 security schemes.
The properties requestTokenUri
, authorizationTokenUri
, and tokenCredentialsUri
in settings
nodes were not validated in OAuth 1.0 security schemes.
Examples defined for queryString
nodes were not appearing in the documentation pane.
The text editor incorrectly allowed the YAML multi-document tag ---
. Now, the editor flags this tag as a syntax error.
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.
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.
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.
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)
The button highlighted by default in the Replace File? dialog is now Keep Both rather than Replace.
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.
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.
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'
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" }
July 25, 2020
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.
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.
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.
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" } } } }
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 ] } ]
June 27, 2020
This release includes new features and fixes issues.
Limited support for OAS 3.0
For details, see OpenAPI Specification 3.0 Support.
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
For details, see Differences for OAS 3.0 in Rendered Documentation.
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.
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.
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
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 specification 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.
May 30, 2020
This release includes new features and fixes several issues.
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.
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.
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
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.
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:
Click the name of the dependency.
Select Change version.
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.
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.
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
April 4, 2020
This release includes several new features, two enhancements, several fixes, and several improvements to how the text editor validates specifications.
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>
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>
When you are working in the text editor on files written in RAML, you can now hold the command key and click on the file name in an !include
tag to open that file.
When a line of text in a file in the text editor is underlined red, indicating that there are one or more errors in the line you can click in the line to see the error message or messages.
In the visual editor, changing a data type’s minimum and maximum lengths could result in these lengths being changed for other data types, too.
If you view the asset page for an API specification in Anypoint Exchange, you can click View Code to open the specification in read-only mode in the text editor of API Designer. The issue was that, if you tried to view different files in an API specification after entering read-only mode this way, the text editor displayed the error message "The requested resource could not be found."
API Designer did not flag as invalid cases in which a property was defined as a numeric or object type, but then overridden with type "any", which is less restrictive.
The text editor displayed the error message Should NOT be longer than n characters at …
because it incorrectly invalidated inheritance in examples.
Some properties defined in API specifications written in RAML appeared in the Types section in the left pane of the asset page in Anypoint Exchange.
Endpoints were sometimes not grouped and listed correctly in the Documentation pane.
Microsoft Internet Explorer 11 closed unexpectedly when opening API Designer projects.
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.
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:
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": {} }
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.
March 7, 2020
This release includes one enhancement, seven fixes, and four improvements to how API specifications are validated.
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 text editor no longer suggests the usage
facet for any types of RAML fragment other than ResourceType, Trait, Library, Overlay, and Extension.
In the text editor, files were allowed to be renamed to include characters that broke the process for publishing to Anypoint Exchange.
In the text editor, API specifications written in OAS 2.0 generated errors if their first line was composed of three dashes or if a line of three dashes followed directives.
--- swagger: "2.0" info: description: This API is written in OAS 2.0. version: "1.0" title: api-in-oas
%YAML 2.0 %TAG !/directive/ --- swagger: "2.0" info: description: This API is written in OAS 2.0. version: "1.0" title: configuration-exp-api-consul
In certain cases, starting a project from an existing example generated an error.
It was possible to create an OAS 2.0 (JSON) project named "exchange", which led to a malformed initial file because of the conflict with the metadata file "exchange.json".
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.
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" }
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" } ] } } } }
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" } ] }
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" }
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.
February 6, 2020
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.
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.
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.
The dialog for publishing API specifications has been simplified.
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.
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.
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. |
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.
Disables 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.
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 ]
January 11, 2020
This release includes seven enhancements, twenty fixes, and three improvements to how API specifications are validated.
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:
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.
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.
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.
Users without the Design Center Developer permission could open projects. Now, if a user does not have this permission, the user cannot view the list of projects in Design Center or open a project by visiting the URL.
The Experience API responded with a 403 in a particular case, but a project was still created.
The visual editor displayed an error when a data type was defined as nil and the example used a null value. Several fixes were made to the Undo/Redo feature in the visual editor.
Using the $schema
keyword with a custom URI caused the following error: Warning: Unable to load schema from <custom URI>. No schema request service available.
The schemaLocation
attribute now loads the location of a referenced XML schema.
The locations of XML schemas to import were not being resolved.
For the fragment types Data Type, Documentation, Extension, Library, Overlay, and Security Scheme, the message Base URI not defined in the API file
no longer appears in API Console.
Code samples generated in API Console for resource methods sometimes included errors.
Boolean properties were rendered by API Console as strings in payloads before being passed to the mocking service in method bodies.
Spaces in URI parameters were encoded by API Console as +
rather than as %20
in URIs generated by the mocking service.
Large API specifications would not appear in API Console in some cases.
XML-wrapped examples in specifications written in RAML were not parsed correctly in API Console.
A specification written in OAS caused the mocking service to fail with the error `org.json.JSONException: Duplicate key "<name of key>” at…'.
The content of the summary
field in specifications written in OAS did not appear in API Console.
API Console was rendering integers as strings.
When a specification written in OAS had internal references to schema definitions, this message appeared in API Console in the body of the responses for a method: The API file specifies body for this request but it does not specify the data model.
When the mocking service was used for a GET request for which the authorization method was x-clientIDSecret, the message Fill in required parameters
appeared even when the Client-id and Client-Secret fields in API Console were filled in.
API Console added tags to XML examples that contained arrays.
The text editor now accepts as valid non-Boolean values for the additionalItems
keyword, which is part of JSON Schema.
According to JSON Schema (https://json-schema.org/understanding-json-schema/reference/array.html#tuple-validation), the |
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
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.
You can now add custom headers when using the mocking service to test endpoints in API specifications that you are developing in the visual editor.
You might experience a delay of a few seconds When you switch between branches of a project in the text editor. Now, a message appears that shows the progress in switching to the selected branch.
In Google Chrome, the text editor displayed no error messages for a project. However, the text editor displayed many error messages for the same project in Mozilla Firefox.
A test request for a file made to the mocking service from a browser correctly resulted in the downloading of the file. However, test requests for the same file made to the mocking service from within API Designer and Exchange did not result in the downloading of the file, even though a status code of 200 was returned.
The error message Error publishing to Exchange: Nout found
appeared in the following scenario:
Create an API-specification project in the text editor.
Go to the Dependencies panel and consume one or more Exchange assets.
Close the project.
Go to Exchange and delete one of the two consumed assets.
Return to API Designer and reopen the project.
Try to publish the API specification to Exchange.
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’.
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.
September 7, 2019
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.
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.
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.
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.
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.
August 10, 2019
This release introduces two new features and fixes several issues.
You can now see a list of API-specification projects and API-fragment projects that you recently opened or created. In the top-left corner of your browser window, click the three lines to the left of the Design Center logo.
For projects created before January 10, 2019: If no errors appear in your project when the switch that is labeled Show Strict Errors is toggled off, and if errors do appear in your project when that switch is toggled on, a countdown timer appears to the left of the Publish button to remind you of how many days you have left to resolve the errors. If the timer for such a project expires before you have resolved the errors, you will not be able to publish the specification to Exchange until you have done so.
Published copies of complex API specifications in RAML on Exchange were truncated by 20 characters.
API specifications in RAML that included Arabic characters could not be published to Exchange.
JSON examples that included umlauts could not be uploaded to API Designer by means of the Save API.
In some cases, publishing an API specification in RAML to Exchange resulted in the last few characters of the specification not appearing in Exchange.
Importing an asset from Exchange that included dependencies could result in an error message similar to this one: Unexpected token o in JSON at position 1
.
An !include
in a type
definition was incorrectly causing the error message Error while parsing file. at (1,0)
to appear.
The API Designer xAPI was truncating the last line from specifications that were uploaded to projects by means of Anypoint CLI.
During attempts to publish an API specification in RAML, the Main file field in the Publish API Specification dialog was blank and the specification could not be published. However, if the specification was imported into a new project, then publishing it to Exchange was possible.
The validation process was erroneously generating the message Recursive type at (0,1)
for a particular API specification in RAML.
The fractional-seconds (ff
) part of the date-time format yyyy-mm-ddThh:mm:ss[.ff…]
was not supported by the mocking service, which expected the format yyyy-MM-dd’T’HH:mm:ss
.
The validation process would erroneously display an Unresolved reference
error message for JSON schemas that referenced other JSON schemas by using relative paths.
July 13, 2019
This release introduces two enhancements and fixes several issues.
When you republish a project to Exchange, you now can edit the name only in Exchange. This enhancement prevents naming conflicts. Due to this change, three fields are disabled in the Publish to Exchange dialog when you republish a project: Name, Group ID, and Asset ID.
The Publish to Exchange button is now disabled if your user ID does not have the role either of Exchange Contributor or Exchange Administrator. Disabling the button prevents you from filling in the Publish to Exchange dialog only to receive an error message if your user ID does not have a required role.
Design Center presented a false positive Warning message of different values for the discriminator
value.
AMF showed a Warning message of an unused parameter when using the declared uriParameter
in a resource type.
In an AMF implementation, using NamedExample
inside a NamedExample did not work with Exchange and API Designer.
Design Center allowed the first line in a RAML API definition document to be blank.
The [object Object] error shows up when typing a path to a filename and referencing a directory.
June 15, 2019
This release introduces several new features in the visual 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.
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.
When you are using Microsoft Internet Explorer or Microsoft Edge as your browser and you click Design Center or the hamburger menu in the top-left corner as you are using the text editor, there is no longer a browser pop-up asking whether you want to leave the page.
It is now possible to view inline documentation for errors if you are using Microsoft Internet Explorer, Microsoft Edge, or Mozilla Firefox as your browser. Click the information icon that appears next to error messages.
Changes made in the text editor might take up to six minutes to be parsed.
In the text editor, creating a fragment in an API-specification project, leaving the fragment without content, and then adding a reference to it from the main file before adding content to the fragment, caused the reference to be parsed as an error.
Underscores, spaces, and hyphen were not parsed as separator characters in variables in resourceTypes.
It was possible to create API specifications without the appropriate entitlement.
Very long names of API-specification projects are now better supported. If the name of a branch does not appear because the name of a project is too long, you can move your mouse over the path of the branch to see the full path. If the name of a project is too long to be seen all at once in the Publish API Specification to Exchange dialog, you can scroll though the field in which the name appears.
When an API specification included the definition of a type with an !include
tag and the example of the type was also included with an !include
tag, then the following message appeared:
should have required property '<name of property>' at <name of file>.raml
Here are examples of an API specification, a data type, and an example that would produce this error:
#%RAML 1.0 title: ac-dgt-xcpr types: DigitalProfileCreateRequest: type: !include dataType.raml examples: DigitalProfileCreateRequest_Example: !include example.raml /profiles: post: body: application/json: DigitalProfileCreateRequest
#%RAML 1.0 DataType type: object properties: customerProfile: type: object properties: password: type: string
#%RAML 1.0 NamedExample "customerProfile": { "password": "abc123" }
For certain API specifications, the API console was not appearing.
Not all types were being displayed in the list of types in the API console.
When a specification defines a boolean value but does not provide a default value, the API console now provides a default value. Doing so prevents problems from arising with the mocking service.
In some cases, an API-specification project might never finish loading when an attempt was made to open it.
API specifications that included binary files were not displayed properly in Exchange after being published. To ensure that binary files appear properly for API specifications that were created in previous releases of API Designer, follow these steps:
Delete the binary file from your API-specification project.
Import the binary file again into your project.
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.
May 18, 2019
This release introduces three new features and an enhancement, and it fixes several issues. There is also one known issue.
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.
The dialog for creating projects in API Designer has been redesigned for a simpler experience.
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:
Create a RAML fragment and publish it as version 1.0.0 to Exchange.
Create a RAML API specification, import the fragment, and publish the API specification to Exchange.
Open the RAML fragment created in step 1, edit it, and publish it as version 1.0.1.
Create a new project and RAML API specification, import version 1.0.1 of the fragment.
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.
April 20, 2019
This release includes two new features and several fixes. There is also one known issue.
You can now import projects directly from Exchange. You no longer have to download a project from Exchange to your computer or other location, and then import it into a new project in API Designer. See Import Files into an API Project for the steps.
If you define a global media type in a specification in the visual API editor, you no longer are required to select a media type when you define the body of a response for a method. Instead, you can now leave the option default
specified. This option is available only if a global media type is defined.
Specifications that were several MB in size could not be published to Exchange. Now, for both the importing of projects from Exchange and the publishing projects to Exchange, the .zip files are reduced in size, preventing such errors.
Resource types and traits in API specifications that were written in RAML 1.0 were not being validated.
A project might never finish loading if you created the project in the visual API editor, created a data type in that project, closed the project, and then attempted to reopen the project.
The API editor returned the error message Recursive type at (x, y)
for recursive DataType definitions.
The mocking service would fail if an API specification used the example
facet, rather than the examples
facet, to include a NamedExample fragment.
The API console might display all examples for all methods that were in a specification, not just the examples for the selected method.
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.
April 6, 2019
This release includes a new feature, two enhancements, and two fixes.
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.
The usability of the feature for forking projects is improved.
The navigation bar at the top of API Designer is now consistent with the navigation bars in other tools within Design Center.
The option API is behind a firewall, which you can toggle on and off by clicking the shield that is on the left side of the toggle for the mocking service, was not functional.
The validation of headers was not occurring when the headers were defined in RAML files that were included as dependencies from Anypoint Exchange.
API Designer did not release a user’s lock on a project branch if the user left the project in the API editor by clicking the hamburger icon (the stack of three horizontal bars) in the top-left corner of the screen. Subsequently, no other user could edit the project branch until the previous user opened the project, opened the branch, and then left the project by clicking Design Center to the right of the hamburger icon.
March 23, 2019
This release fixes six 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.
February 23, 2019
This release fixes two 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.
February 9, 2019
This release fixes a number of 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.
January 25, 2019
This release includes enhancements and fixes a number of issues.
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.
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.
January 10, 2019
This release includes several enhancements and fixes a number of issues.
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. |
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.
July 26, 2018
This release introduces a change and fixes for several issues.
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
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.
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.
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.