Appendix: Swagger Extended Definitions for Custom Backends

Overview

Building on the basic Swagger definitions, ROMA Connect extends the definitions of APIs to the authentication mode and function script definition. This section describes the extended definitions for custom backends.

1: x-livedata-auth-type

Meaning: Swagger-based apiKey authentication format, which defines an authentication mode provided by the custom backend.

Scope of effect: Security Scheme Object

Example

securityDefinitions:
  customize-name-signature:
    type: "apiKey"
    name: "Authorization"
    in: "header"
    x-livedata-auth-type: "SIGNATURE"
    x-livedata-signature:
      key: "signatureKey"
      secret: "signatureSecret"

**Table 1** Parameter description
Parameter	Mandatory	Type	Description
type	Yes	String	Authentication type. Only apiKey is supported.
name	Yes	String	Name of the parameter used for authentication. Set this parameter to Authorization.
in	Yes	String	Location of the parameter. Only header is supported.
description	No	String	Description of the parameter.
x-livedata-auth-type	Yes	String	Custom backend authentication mode. The value can only be SIGNATURE.
x-livedata-signature.key	No	String	Key required for signature.
x-livedata-signature.secret	No	String	Secret required for signature.

2: x-livedata-version

Meaning: version number of the custom backend.

Scope of effect: Operation Object

Example

paths:
  '/path':
    get:
      x-livedata-version: '1.0.1'

**Table 2** Parameter description
Parameter	Mandatory	Type	Description
x-livedata-version	Yes	String	API version.

3: x-livedata-status

Meaning: Custom backend status.

Scope of effect: Operation Object

Example

paths:
  '/path':
    get:
      x-livedata-status: 'DESIGNED'

**Table 3** Parameter description
Parameter	Mandatory	Type	Description
x-livedata-status	Yes	String	Status of the custom backend. The options are DESIGNED, DEVELOPED, TESTED, and DEPLOYED. DESIGNED: The custom backend has been designed and is to be developed. DEVELOPED: The custom backend has been developed and is to be tested. TESTED: The custom backend has been tested and is to be deployed. DEPLOYED: The custom backend has been deployed.

4: x-livedata-roma-app

Meaning: Integration application bound to the custom backend.

Scope of effect: Operation Object

Example

paths:
  '/path':
    get:
      x-livedata-roma-app: 'romaAppName'

**Table 4** Parameter description
Parameter	Mandatory	Type	Description
x-livedata-roma-app	Yes	String	Integration application bound to the custom backend.

5: x-livedata-scripts

Meaning: custom backend definition script.

Scope of effect: Operation Object

Example

paths:
  '/path':
    get:
      produces:
        - "application/json"
      responses:
        default:
          description: "default response"
      x-livedata-scripts:
        - type: "function"
          content: "custom-script-content"
          result: "func"

**Table 5** Parameter description
Parameter	Mandatory	Type	Description
content	Yes	String	Script statement, which is a character string encoded using Base64. The actual script needs to be decoded using Base64.
result	Yes	String	Return object. The execution result of the statement will be encapsulated in the object and returned. This parameter is valid only for data backends, not function backends.
type	Yes	String	Script type. The options are Function, SQL, and SP.
datasources	No	x-livedata-scripts.datasources	Data source definition.

5.1 x-livedata-scripts.datasources

Meaning: data source definition of the custom backend.

Scope of effect: x-livedata-scripts

Example

paths:
  '/users':
    get:
      produces:
        - "application/json"
      responses:
        default:
          description: "default response"
      x-livedata-scripts:
        - type: "function"
          content: "custom-script-content"
          result: "custom-script-result"
          datasource:
            name: "custom-datasource-name"