Release Notes 0.5.1 – Swagger support

Date: May 2, 2018

What’s New?

Support for swagger 2.0 specifications written in YAML or JSON.
Supports specifications written in YAML or JSON

Create a new Swagger 2.0 specification from the ‘File > New’ context menu.
Create new Swagger 2.0 specification

If an error occurs, you can send us an error report by clicking the ‘Send to Senya’ button in the error dialog. The error report creates a new issue in the issue tracker.
Create new issue, when error report is sent

Swagger 2.0 completions for:
– Property names.
– Property values with a fixed amount of values, e.g. the schemes property where array values can be http, https, ws or wss.
– Suggested values for mime-types, HTTP status codes and software licenses.
– Basic support for JSON reference completions.

Insert template for required properties and fixed values, e.g. when you choose ‘info’ from the completions, a new info object is created with its required properties version and title.
Insert template demonstration

Validate the Swagger 2.0 specification:
– Valid type, e.g. show an error when an object is defined, but an array was expected.
– Valid property names.

  • Most objects only allow a set of predefined property names. An error message is shown if the property name is not allowed.
  • Other objects require its properties to be in a certain format, e.g. the paths object where each property name has to start with a leading slash.
  • Check that properties aren’t defined multiple times in the same object. This applies to tags and operation parameters.

– Required properties, e.g. at least one status code as property in the responses object.
– Property value validations. Make sure the value is in the right format. This applies to the host, basePath, urls, emails, mime-types, schema examples, etc.
– Specification validations. Validations that go beyond the validation of property names and values.

  • Make sure all operationId values are unique.
  • Validate that a path item’s parameters don’t include duplicate parameters. A unique parameter is defined by a combination of its ‘name’ and ‘in’ values.
  • If a parameter’s ‘in’ value is ‘path’, then the ‘name’ value must correspond to the associated path segment from the path property name in the paths object.
  • There can only be one body parameter for a path item.
  • If the discriminator property is used in a schema object, then its value must point to a property defined in this schema and this property must be in the required property list.
  • For path items that are a json reference, the referenced structure must be in the format of a path item object.
  • If an operation response example is specified then the property name must be one of the ‘produces’ values.
    If ‘produces’ is not specified (either globally or on operation level), then any valid mime-type is allowed.
  • In the security object, the name used for each property must correspond to a security scheme declared in the security definitions.
    If the property name corresponds to a security scheme that is of type ‘oauth2’, then the value is a list of scope names.
    For all other security scheme types, the array must be empty.

Known problems

Error messages for schema object errors are most of the time misleading.
A good example of this is when you have defined type number without a format.
It will show an error message: ‘Invalid value, expected: boolean’, while it should say ‘Required property format missing’.
Invalid value known problem