Skip to content

Changes in 4.4.0
Compare
Choose a tag to compare
@tomsfernandez tomsfernandez released this 21 Oct 14:33
· 2954 commits to master since this release
4.4.0
b584f9d
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.

Released Oct 21, 2020.

JS asset

JVM asset

AML 5.0.x adopted

This release adopts AML 5.0.x. This AML release includes an amf-validation module split which is now part of the AML project.

For amf-client/amf-webapi adopters there is no action required to adopt these change unless you are manually initializing validation.

All the datails in: AML 5.0.x release notes

Interface Changes

OAS Compacted Emission

New parameter in client interface RenderOptions to disable compact emission in OAS (2.0 and 3.0)

Added

  • amf.client.render.RenderOptions.isWithCompactedEmission
  • amf.client.render.RenderOptions.withCompactedEmission

AsyncAPI (still beta) updated kafka bindings

Changed

  • amf.client.model.domain.KafkaMessageBinding.messageKey(..) changed its return type from amf.core.model.StrField to amf.client.model.domain.Shape
  • amf.client.model.domain.KafkaMessageBinding.withKey(..) now receives amf.client.model.domain.Shape instead of String
  • amf.client.model.domain.KafkaOperationBinding.clientId(..) changed its return type from amf.client.model.StrField to amf.client.model.domain.Shape
  • amf.client.model.domain.KafkaOperationBinding.groupId(..) changed its return type from amf.client.model.StrField to amf.client.model.domain.Shape
  • amf.client.model.domain.KafkaOperationBinding.withClientId(..) now receives amf.client.model.domain.Shape instead of String
  • amf.client.model.domain.KafkaOperationBinding.withGroupId(..) now receives amf.client.model.domain.Shape instead of String

Validation Changes

AsyncAPI (still beta) kafka operation and message binding change type value for keys 'groupId', 'clientId', and 'key'

These keys where parsed as string values, and are now defined as Schema Object's.
Kafka operation binding with modified 'groupId' and 'clientId' values:

publish:
  bindings:
    kafka:
      groupId:
        type: string
        pattern: '^[\w]+\.[\w]+\.[\w]+\.[\d]+$'
      clientId:
        type: string
        enum: ['myClientId']

Kafka message binding with modified 'key' value:

message:
  bindings:
    kafka:
      key:
        type: string
        maxLength: 20

AsyncAPI (still beta) allow reference to external RAML data types

Three new mechanisms have been introduced to enable referencing RAML data types present in fragments, libraries, or external files. The ‘$ref’ facet may only be used at the root of the payload definition, and its target content must be valid structurally according to the RAML specification.

Referencing external RAML data type fragments. Relative pointer is not support for this use case.

message:
  schemaFormat: application/vnd.rai.raml;version=1.0
  payload:
    $ref: external-data-type.raml

Referencing types present in libraries, the following fixed pointer must be used “{lib}#/types/{typeName}”.

message:
  schemaFormat: application/vnd.rai.raml;version=1.0
  payload:
    $ref: external-library.raml#/types/User

RAML content present in external yaml files can be referenced and the use of relative json pointers may be used.

message:
  schemaFormat: application/vnd.rai.raml;version=1.0
  payload:
    $ref: external-yaml.yaml#/nestedContent/User

Within the definition of RAML content, it is not possible to directly reference content defined in the async api. The following example is invalid as the type 'User' will result in an unresolved reference.

components:
  schemas:
    User:
      type: string

channels:
  users/signup:
    subscribe:
      message:
        schemaFormat: application/vnd.rai.raml;version=1.0
        payload:
          type: User

File Order Inconsistency

We changed the way file references were added to the BaseUnit. Before, files didn't respect the order in which the API author added them. Now, the order of the files in the references() node respects the original API order. This helps keeping consistency between API parsing processes.

Note: although we make reference to "order", order is not guaranteed in AMF as AMF is a graph and graph edges don't have a specific order.

For the api:

#%RAML 1.0

types:
  a: !include datatypes/a.raml
  b: !include datatypes/b.raml
  c: !include datatypes/c.raml
  h: !include datatypes/h.raml

Before a possible json-ld with inconsistent reference order could be:

{
  "doc:references": [
    {
      "id": "./datatypes/c.raml",
      ...
    },
    {
      "id": "./datatypes/h.raml",
      ...
    },
    {
      "id": "./datatypes/a.raml",
      ...
    },
    {
      "id": "./datatypes/b.raml",
      ...
    }
  ]
}

Now, it respects the ordering in the API:

{
  "doc:references": [
    {
      "id": "./datatypes/a.raml",
      ...
    },
    {
      "id": "./datatypes/b.raml",
      ...
    },
    {
      "id": "./datatypes/c.raml",
      ...
    },
    {
      "id": "./datatypes/d.raml",
      ...
    }
  ]
}

AMF Fixed issues

Assets 2
Loading