From 5124b1f8d7a2ab23c73923eb453ae7d437b90dd5 Mon Sep 17 00:00:00 2001 From: Elian Kraja Date: Wed, 26 Sep 2018 15:48:58 +0200 Subject: [PATCH] Completed VNF Indicator Interface --- .../IndividualSubscription.robot | 109 + .../IndividualVNFindicator.robot | 102 + .../SOL003-VNFIndicator-API.yaml | 5080 +++++++++++++++++ .../VNFIndicator-API_nxw/Subscriptions.robot | 161 + .../VNFIndicator-API_nxw/VNFIndicators.robot | 132 + .../VnfIndicatorsInVnfInstanceId.robot | 131 + .../environment/generic.txt | 18 + .../environment/individualSubscription.txt | 3 + .../environment/individualVnfIndicator.txt | 4 + .../environment/subscriptions.txt | 7 + .../environment/vnfIndicatorinVnfInstance.txt | 5 + .../environment/vnfIndicators.txt | 3 + .../jsons/subscriptios.json | 3 + .../VnfIndicatorSubscription.schema.json | 1 + .../schemas/vnfIndicators.schema.json | 1 + .../IndividualSubscription.robot | 12 +- .../IndividualVNFPackage.robot | 1 + .../Subscriptions.robot | 1 + .../VNFDInIndividualVNFPackage.robot | 1 + .../VNFPackageArtifacts.robot | 1 + .../VNFPackageContent.robot | 1 + .../VNFPackages.robot | 26 +- 22 files changed, 5779 insertions(+), 24 deletions(-) create mode 100644 SOL003/VNFIndicator-API_nxw/IndividualSubscription.robot create mode 100644 SOL003/VNFIndicator-API_nxw/IndividualVNFindicator.robot create mode 100644 SOL003/VNFIndicator-API_nxw/SOL003-VNFIndicator-API.yaml create mode 100644 SOL003/VNFIndicator-API_nxw/Subscriptions.robot create mode 100644 SOL003/VNFIndicator-API_nxw/VNFIndicators.robot create mode 100644 SOL003/VNFIndicator-API_nxw/VnfIndicatorsInVnfInstanceId.robot create mode 100644 SOL003/VNFIndicator-API_nxw/environment/generic.txt create mode 100644 SOL003/VNFIndicator-API_nxw/environment/individualSubscription.txt create mode 100644 SOL003/VNFIndicator-API_nxw/environment/individualVnfIndicator.txt create mode 100644 SOL003/VNFIndicator-API_nxw/environment/subscriptions.txt create mode 100644 SOL003/VNFIndicator-API_nxw/environment/vnfIndicatorinVnfInstance.txt create mode 100644 SOL003/VNFIndicator-API_nxw/environment/vnfIndicators.txt create mode 100644 SOL003/VNFIndicator-API_nxw/jsons/subscriptios.json create mode 100644 SOL003/VNFIndicator-API_nxw/schemas/VnfIndicatorSubscription.schema.json create mode 100644 SOL003/VNFIndicator-API_nxw/schemas/vnfIndicators.schema.json diff --git a/SOL003/VNFIndicator-API_nxw/IndividualSubscription.robot b/SOL003/VNFIndicator-API_nxw/IndividualSubscription.robot new file mode 100644 index 00000000..b30d469d --- /dev/null +++ b/SOL003/VNFIndicator-API_nxw/IndividualSubscription.robot @@ -0,0 +1,109 @@ +*** Settings *** +Library HttpLibrary.HTTP +Library JSONSchemaLibrary schemas/ +Resource environment/generic.txt # Generic Parameters +Resource environment/individualSubscription.txt +Library OperatingSystem + +*** Test Cases *** +GET Individual Subscription + Log Trying to get a given subscription identified by subscriptionId + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + GET ${apiRoot}/${apiName}/${apiVersion}/subscriptions/${subscriptionId} + Response Status Code Should Equal 200 + Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} + Log Received a 200 OK as expected + ${result}= Get Response Body + ${json}= evaluate json.loads('''${result}''') json + Validate Json VnfIndicatorSubscriptions.schema.json ${json} + Log Validated VnfIndicatorSubscription schema + +GET Subscription - Negative (Not Found) + Log Trying to perform a request on a subscriptionID which doesn't exist + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + GET ${apiRoot}/${apiName}/${apiVersion}/subscriptions/${erroneousSubscriptionId} + Response Status Code Should Equal 404 + Log Received 404 Not Found as expected + ${problemDetails}= Get Response Body + ${json}= evaluate json.loads('''${problemDetails}''') json + Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} + Log Trying to validate ProblemDetails + Validate Json ProblemDetails.schema.json ${json} + Log Validation OK + +GET Subscription - Negative (Unauthorized: Wrong Token) + Log Trying to perform a negative get, using wrong authorization bearer + Pass Execution If ${VNFM_AUTH_USAGE} == 0 Skipping test as NFVO is not supporting authentication + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + GET ${apiRoot}/${apiName}/${apiVersion}/subscriptions/${subscriptionId} + Response Status Code Should Equal 401 + Log Received 401 Unauthorized as expected + ${problemDetails}= Get Response Body + ${json}= evaluate json.loads('''${problemDetails}''') json + Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} + Log Trying to validate ProblemDetails + Validate Json ProblemDetails.schema.json ${json} + Log Validation OK + +DELETE Subscription + Log Trying to perform a DELETE on a subscriptionId + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + DELETE ${apiRoot}/${apiName}/${apiVersion}/subscriptions/${subscriptionId} + Response Status Code Should Equal 204 + Log Received 204 No Content as expected + Log Trying to get the deleted element + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + GET ${apiRoot}/${apiName}/${apiVersion}/subscriptions/${subscriptionId} + Response Status Code Should Equal 404 + Log The subscriptionId is not present in database + +DELETE Subscription - Negative (Not Found) + Log Trying to perform a DELETE on a subscriptionId which doesn't exist + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + DELETE ${apiRoot}/${apiName}/${apiVersion}/subscriptions/${erroneousSubscriptionId} + Response Status Code Should Equal 404 + Log The subscriptionId is not present in database + ${problemDetails}= Get Response Body + ${json}= evaluate json.loads('''${problemDetails}''') json + Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} + Log Trying to validate ProblemDetails + Validate Json ProblemDetails.schema.json ${json} + Log Validation OK + +PUT Subscription - (Method not implemented) + Log Trying to perform a PUT. This method should not be implemented + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + PUT ${apiRoot}/${apiName}/${apiVersion}/subscriptions/${subscriptionId} + Response Status Code Should Equal 405 + Log Received 405 Method not implemented as expected + +PATCH Subscription - (Method not implemented) + Log Trying to perform a PATCH. This method should not be implemented + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + Http Request PATCH ${apiRoot}/${apiName}/${apiVersion}/subscriptions/${subscriptionId} + Response Status Code Should Equal 405 + Log Received 405 Method not implemented as expected + +POST Subscription - (Method not implemented) + Log Trying to perform a POST. This method should not be implemented + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + POST ${apiRoot}/${apiName}/${apiVersion}/subscriptions/${subscriptionId} + Response Status Code Should Equal 405 + Log Received 405 Method not implemented as expected diff --git a/SOL003/VNFIndicator-API_nxw/IndividualVNFindicator.robot b/SOL003/VNFIndicator-API_nxw/IndividualVNFindicator.robot new file mode 100644 index 00000000..4ef4c316 --- /dev/null +++ b/SOL003/VNFIndicator-API_nxw/IndividualVNFindicator.robot @@ -0,0 +1,102 @@ +*** Settings *** +Library HttpLibrary.HTTP +Library JSONSchemaLibrary schemas/ +Resource environment/generic.txt # Generic Parameters +Resource environment/individualVnfIndicator.txt + +*** Test Cases *** +GET Individual VNF Indicator + Log The GET method reads a VNF indicator. + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + GET ${apiRoot}/${apiName}/${apiVersion}/indicators/${vnfInstanceId}/${indicatorId} + Response Status Code Should Equal 200 + ${result}= Get Response Body + ${json}= evaluate json.loads('''${vnfPkgInfo}''') json + Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} + Log Trying to validate response + Validate Json vnfIndicators.schema.json ${json} + Log Validation OK + +GET Individual VNF Indicator - Negative (Not Found) + Log Trying to perform a negative get, using an erroneous package ID + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + GET ${apiRoot}/${apiName}/${apiVersion}/indicators/${vnfInstanceId}/${erroneousIndicatorId} + Response Status Code Should Equal 404 + Log Received 404 Not Found as expected + ${problemDetails}= Get Response Body + ${json}= evaluate json.loads('''${problemDetails}''') json + Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} + Log Trying to validate ProblemDetails + Validate Json ProblemDetails.schema.json ${json} + Log Validation OK + +GET Individual VNF Indicator - Negative (Unauthorized: Wrong Token) + Log Trying to perform a negative get, using wrong authorization bearer + Pass Execution If ${VNFM_AUTH_USAGE} == 0 Skipping test as NFVO is not supporting authentication + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Set Request Header Authorization ${NEG_AUTHORIZATION} + GET ${apiRoot}/${apiName}/${apiVersion}/indicators/${vnfInstanceId}/${indicatorId} + Response Status Code Should Equal 401 + Log Received 401 Unauthorized as expected + ${problemDetails}= Get Response Body + ${json}= evaluate json.loads('''${problemDetails}''') json + Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} + Log Trying to validate ProblemDetails + Validate Json ProblemDetails.schema.json ${json} + Log Validation OK + +GET Individual VNF Indicator - Negative (Unauthorized: No Token) + Log Trying to perform a negative get, without authentication token. + Pass Execution If ${VNFM_AUTH_USAGE} == 0 Skipping test as NFVO is not supporting authentication + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + GET ${apiRoot}/${apiName}/${apiVersion}/indicators/${vnfInstanceId}/${indicatorId} + Response Status Code Should Equal 401 + Log Received 401 Unauthozired as expected + ${problemDetails}= Get Response Body + ${json}= evaluate json.loads('''${problemDetails}''') json + Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} + Log Trying to validate ProblemDetails + Validate Json ProblemDetails.schema.json ${json} + Log Validation OK + +POST Individual VNF Indicator (Method not implemented) + Log Trying to perform a POST (method should not be implemented) + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + POST ${apiRoot}/${apiName}/${apiVersion}/indicators/${vnfInstanceId}/${indicatorId} + Response Status Code Should Equal 405 + Log Received 405 Method not implemented as expected + +PUT Individual VNF Indicator (Method not implemented) + Log Trying to perform a PUT. This method should not be implemented + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + PUT ${apiRoot}/${apiName}/${apiVersion}/indicators/${vnfInstanceId}/${indicatorId} + Response Status Code Should Equal 405 + Log Received 405 Method not implemented as expected + +PATCH Individual VNF Indicator (Method not implemented) + Log Trying to perform a PATCH. This method should not be implemented + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + Http Request PATCH ${apiRoot}/${apiName}/${apiVersion}/indicators/${vnfInstanceId}/${indicatorId} + Response Status Code Should Equal 405 + Log Received 405 Method not implemented as expected + +DELETE Individual VNF Indicator (Method not implemented) + Log Trying to perform a DELETE. This method should not be implemented + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + DELETE ${apiRoot}/${apiName}/${apiVersion}/indicators/${vnfInstanceId}/${indicatorId} + Response Status Code Should Equal 405 + Log Received 405 Method not implemented as expected diff --git a/SOL003/VNFIndicator-API_nxw/SOL003-VNFIndicator-API.yaml b/SOL003/VNFIndicator-API_nxw/SOL003-VNFIndicator-API.yaml new file mode 100644 index 00000000..54b7454a --- /dev/null +++ b/SOL003/VNFIndicator-API_nxw/SOL003-VNFIndicator-API.yaml @@ -0,0 +1,5080 @@ +swagger: '2.0' +info: + version: 1.1.1 + title: SOL003 - VNF Indicator interface + description: > + SOL003 - VNF Indicator interface + + + IMPORTANT: Please note that this file might be not aligned to the current + version of the ETSI Group Specification it refers to. In case of + discrepancies the published ETSI Group Specification takes precedence. + + + In clause 4.3.2 of ETSI GS NFV-SOL 003 v2.4.1, an attribute-based filtering + mechanism is defined. This mechanism is currently not included in the + corresponding OpenAPI design for this GS version. Changes to the + attribute-based filtering mechanism are being considered in v2.5.1 of this + GS for inclusion in the corresponding future ETSI NFV OpenAPI design. Please + report bugs to + https://forge.etsi.org/bugzilla/buglist.cgi?component=Nfv-Openapis&list_id=61&product=NFV&resolution= + license: + name: ETSI Forge copyright notice + url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt' +externalDocs: + description: ETSI GS NFV-SOL 003 V2.4.1 + url: >- + http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/02.04.01_60/gs_NFV-SOL003v020401p.pdf +basePath: /vnfind/v1 +schemes: + - https +consumes: + - application/json +produces: + - application/json +paths: + /indicators: + get: + description: | + Get Indicator Value + + The GET method queries multiple VNF indicators. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231 + in: header + required: true + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235 + in: header + required: false + type: string + responses: + '200': + description: > + OK + + The list of VNF indicators was queried successfully. The response + body shall contain the representations of all VNF indicators that + match the attribute filter. + headers: + Content-Type: + description: > + The MIME type of the body of the request. Reference: IETF RFC + 7231 + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + type: string + maximum: 1 + minimum: 0 + schema: + type: array + items: + description: | + This type represents a VNF indicator value. + type: object + required: + - id + - value + - vnfInstanceId + - _links + properties: + id: + description: | + An identifier that is unique within a VNF descriptor. + type: string + name: + description: > + Human readable name of the indicator. Shall be present if + defined in the VNFD. + type: string + value: + description: > + Provides the value of the indicator. The value format is + defined in the VNFD. ETSI GS NFV-SOL 001 specifies the + structure and format of the VNFD based on TOSCA + specifications. + type: object + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + - vnfInstance + properties: + self: + description: | + This type represents a link to a resource. + type: object + required: + - href + properties: + href: + description: | + URI of the referenced resource. + type: string + format: url + vnfInstance: + description: | + This type represents a link to a resource. + type: object + required: + - href + properties: + href: + description: | + URI of the referenced resource. + type: string + format: url + '400': + description: > + Bad Request + + Invalid attribute-based filtering parameters or Invalid attribute + selector. It fhe request is malformed or syntactically incorrect + (e.g. if the request URI contains incorrect query parameters or a + syntactically incorrect payload body), the API producer shall + respond with this response code. The "ProblemDetails" structure + shall be provided, and should include in the "detail" attribute more + information about the source of the problem. If the request contains + a malformed access token, the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. If there is + an application error related to the client's input that cannot be + easily mapped to any other HTTP response code ("catch all error"), + the API producer shall respond with this response code.The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + type: string + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '401': + description: > + Unauthorized + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + type: string + maximum: 1 + minimum: 0 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '403': + description: > + Forbidden + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '405': + description: > + Method Not Allowed + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted in that case. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '406': + description: > + Not Acceptable + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted in that case. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '500': + description: > + Internal Server Error + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond withthis response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '503': + description: > + Service Unavailable + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 [13] for + the use of the "Retry-After" HTTP header and for the alternative to + refuse the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '/indicators/{vnfInstanceId}': + parameters: + - name: vnfInstanceId + description: > + Identifier of the VNF instance to which the VNF indicator applies. + This identifier can be retrieved from the resource referenced by the + "Location" HTTP header in the response to a POST request creating a + new VNF instance resource. It can also be retrieved from the "id" + attribute in the payload body of that response. + in: path + type: string + required: true + get: + description: > + Get Indicator Value + + + The GET method queries multiple VNF indicators related to a VNF + instance. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231 + in: header + required: true + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235 + in: header + required: false + type: string + responses: + '200': + description: > + OK + + The list of VNF indicators was queried successfully. The response + body shall contain the representations of all VNF indicators that + are related to the particular VNF instance and that match the + attribute filter. + headers: + Content-Type: + description: > + The MIME type of the body of the request. Reference: IETF RFC + 7231 + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + type: string + maximum: 1 + minimum: 0 + schema: + type: array + items: + description: | + This type represents a VNF indicator value. + type: object + required: + - id + - value + - vnfInstanceId + - _links + properties: + id: + description: | + An identifier that is unique within a VNF descriptor. + type: string + name: + description: > + Human readable name of the indicator. Shall be present if + defined in the VNFD. + type: string + value: + description: > + Provides the value of the indicator. The value format is + defined in the VNFD. ETSI GS NFV-SOL 001 specifies the + structure and format of the VNFD based on TOSCA + specifications. + type: object + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + - vnfInstance + properties: + self: + description: | + This type represents a link to a resource. + type: object + required: + - href + properties: + href: + description: | + URI of the referenced resource. + type: string + format: url + vnfInstance: + description: | + This type represents a link to a resource. + type: object + required: + - href + properties: + href: + description: | + URI of the referenced resource. + type: string + format: url + '400': + description: > + Bad Request + + Invalid attribute-based filtering parameters or Invalid attribute + selector. It fhe request is malformed or syntactically incorrect + (e.g. if the request URI contains incorrect query parameters or a + syntactically incorrect payload body), the API producer shall + respond with this response code. The "ProblemDetails" structure + shall be provided, and should include in the "detail" attribute more + information about the source of the problem. If the request contains + a malformed access token, the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. If there is + an application error related to the client's input that cannot be + easily mapped to any other HTTP response code ("catch all error"), + the API producer shall respond with this response code.The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + type: string + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '401': + description: > + Unauthorized + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + type: string + maximum: 1 + minimum: 0 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '403': + description: > + Forbidden + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '405': + description: > + Method Not Allowed + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted in that case. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '406': + description: > + Not Acceptable + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted in that case. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '500': + description: > + Internal Server Error + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond withthis response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '503': + description: > + Service Unavailable + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 [13] for + the use of the "Retry-After" HTTP header and for the alternative to + refuse the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '/indicators/{vnfInstanceId}/{indicatorId}': + parameters: + - name: indicatorId + description: > + Identifier of the VNF indicator. This identifier can be retrieved from + the resource referenced by the payload body in the response to a POST + request creating a new VNF instance resource. + in: path + type: string + required: true + - name: vnfInstanceId + description: > + Identifier of the VNF instance to which the VNF indicator applies. + This identifier can be retrieved from the resource referenced by the + "Location" HTTP header in the response to a POST request creating a + new VNF instance resource. It can also be retrieved from the "id" + attribute in the payload body of that response. + in: path + type: string + required: true + get: + description: | + Get Indicator Value + + The GET method reads a VNF indicator. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231 + in: header + required: true + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235 + in: header + required: false + type: string + responses: + '200': + description: > + OK + + The VNF indicator was read successfully. The response body shall + contain the representation of the VNF indicator. + headers: + Content-Type: + description: > + The MIME type of the body of the request. Reference: IETF RFC + 7231 + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + type: string + maximum: 1 + minimum: 0 + schema: + description: | + This type represents a VNF indicator value. + type: object + required: + - id + - value + - vnfInstanceId + - _links + properties: + id: + description: | + An identifier that is unique within a VNF descriptor. + type: string + name: + description: > + Human readable name of the indicator. Shall be present if + defined in the VNFD. + type: string + value: + description: > + Provides the value of the indicator. The value format is + defined in the VNFD. ETSI GS NFV-SOL 001 specifies the + structure and format of the VNFD based on TOSCA + specifications. + type: object + vnfInstanceId: + description: | + An identifier with the intention of being globally unique. + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + - vnfInstance + properties: + self: + description: | + This type represents a link to a resource. + type: object + required: + - href + properties: + href: + description: | + URI of the referenced resource. + type: string + format: url + vnfInstance: + description: | + This type represents a link to a resource. + type: object + required: + - href + properties: + href: + description: | + URI of the referenced resource. + type: string + format: url + '400': + description: > + Bad Request + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or a syntactically + incorrect payload body), the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided, and + should include in the "detail" attribute more information about the + source of the problem. If the request contains a malformed access + token, the API producer should respond with this response. The + details of the error shall be returned in the WWW-Authenticate HTTP + header, as defined in IETF RFC 6750 and IETF RFC 7235. The + ProblemDetails structure may be provided. If there is an application + error related to the client's input that cannot be easily mapped to + any other HTTP response code ("catch all error"), the API producer + shall respond with this response code.The "ProblemDetails" structure + shall be provided, and shall include in the "detail" attribute more + information about the source of the problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + type: string + maximum: 1 + minimum: 0 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '401': + description: > + Unauthorized + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + type: string + maximum: 1 + minimum: 0 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '403': + description: > + Forbidden + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '405': + description: > + Method Not Allowed + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted in that case. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '406': + description: > + Not Acceptable + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted in that case. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '500': + description: > + Internal Server Error + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond withthis response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '503': + description: > + Service Unavailable + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 [13] for + the use of the "Retry-After" HTTP header and for the alternative to + refuse the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + /subscriptions: + post: + description: > + Subscribe + + + The POST method creates a new subscription. Creation of two subscription + resources with the same callbackURI and the same filter can result in + performance degradation and will provide duplicates of notifications to + the NFVO, and might make sense only in very rare use cases. + Consequently, the VNFM may either allow creating a subscription resource + if another subscription resource with the same filter and callbackUri + already exists (in which case it shall return the “201 Created” response + code), or may decide to not create a duplicate subscription resource (in + which case it shall return a “303 See Other” response code referencing + the existing subscription resource with the same filter and + callbackUri). + parameters: + - name: VnfIndicatorSubscriptionRequest + description: Details of the subscription to be created. + in: body + required: true + schema: + description: > + This type represents a subscription request related to VNF + indicator value change notifications. + type: object + required: + - callbackUri + properties: + filter: + description: > + This type represents a subscription filter related to + notifications about VNF indicator value changes. At a + particular nesting level in the filter structure, the + following applies: All attributes shall match in order for the + filter to match (logical "and" between different filter + attributes). If an attribute is an array, the attribute shall + match if at least one of the values in the array matches + (logical "or" between the values of one filter attribute). + type: object + properties: + vnfInstanceSubscriptionFilter: + description: > + This type represents subscription filter criteria to match + VNF instances. + type: object + properties: + vnfdIds: + description: > + If present, match VNF instances that were created + based on a VNFD identified by one of the vnfdId values + listed in this attribute. The attributes "vnfdIds" and + "vnfProductsFromProviders" are alternatives to + reference to VNF instances that are based on certain + VNFDs in a filter. They should not be used both in the + same filter instance, but one alternative should be + chosen. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProductsFromProviders: + description: > + If present, match VNF instances that belong to VNF + products from certain providers. The attributes + "vnfdIds" and "vnfProductsFromProviders" are + alternatives to reference to VNF instances that are + based on certain VNFDs in a filter. They should not be + used both in the same filter instance, but one + alternative should be chosen. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + Name of the VNF provider to match. + type: string + vnfProducts: + description: > + If present, match VNF instances that belong to + VNF products with certain product names, from + one particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + Name of the VNF product to match. + type: string + versions: + description: > + If present, match VNF instances that + belong to VNF products with certain + versions and a certain product name, from + one particular provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF instances that + belong to VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfInstanceIds: + description: > + If present, match VNF instances with an instance + identifier listed in this attribute. The attributes + "vnfInstanceIds" and "vnfInstanceNames" are + alternatives to reference to particular VNF Instances + in a filter. They should not be used both in the same + filter instance, but one alternative should be chosen. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceNames: + description: > + If present, match VNF instances with a VNF Instance + Name listed in this attribute. The attributes + "vnfInstanceIds" and "vnfInstanceNames" are + alternatives to reference to particular VNF Instances + in a filter. They should not be used both in the same + filter instance, but one alternative should be chosen. + type: array + items: + type: string + indicatorIds: + description: | + Match particular VNF indicator identifiers. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + callbackUri: + description: | + The URI of the endpoint to send the notification to. + type: string + format: url + authentication: + type: object + required: + - authType + properties: + authType: + description: > + Defines the types of Authentication / Authorization which + the API consumer is willing to accept when receiving a + notification. Permitted values: * BASIC: In every HTTP + request to the notification endpoint, use + HTTP Basic authentication with the client credentials. + * OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the + notification endpoint, use an OAuth 2.0 Bearer token, obtained + using the client credentials grant type. + * TLS_CERT: Every HTTP request to the notification + endpoint is sent + over a mutually authenticated TLS session, i.e. not only the + server is authenticated, but also the client is authenticated + during the TLS tunnel setup. + type: array + items: + type: string + enum: + - BASIC + - OAUTH2_CLIENT_CREDENTIALS + - TLS_CERT + paramsBasic: + description: > + Parameters for authentication/authorization using BASIC. + Shall be present if authType is "BASIC" and the contained + information has not been provisioned out of band. Shall be + absent otherwise. + type: object + properties: + userName: + description: > + Username to be used in HTTP Basic authentication. + Shall be present if it has not been provisioned out of + band. + type: string + password: + description: > + Password to be used in HTTP Basic authentication. + Shall be present if it has not been provisioned out of + band. + type: string + paramsOauth2ClientCredentials: + description: > + Parameters for authentication/authorization using + OAUTH2_CLIENT_CREDENTIALS. Shall be present if authType is + "OAUTH2_CLIENT_CREDENTIALS" and the contained information + has not been provisioned out of band. Shall be absent + otherwise. + type: object + properties: + clientId: + description: > + Client identifier to be used in the access token + request of the OAuth 2.0 client credentials grant + type. Shall be present if it has not been provisioned + out of band. The clientId and clientPassword passed in + a subscription shall not be the same as the clientId + and clientPassword that are used to obtain + authorization for API requests. Client credentials may + differ between subscriptions. The value of + clientPassword should be generated by a random + process. + type: string + clientPassword: + description: > + Client password to be used in the access token request + of the OAuth 2.0 client credentials grant type. Shall + be present if it has not been provisioned out of band. + The clientId and clientPassword passed in a + subscription shall not be the same as the clientId and + clientPassword that are used to obtain authorization + for API requests. Client credentials may differ + between subscriptions. The value of clientPassword + should be generated by a random process. + type: string + tokenEndpoint: + description: | + String formatted according to IETF RFC 3986. + type: string + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231 + in: header + required: true + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235 + in: header + required: false + type: string + responses: + '201': + description: > + Created + + The subscription was created successfully. The response body shall + contain a representation of the created subscription resource. The + HTTP response shall include a "Location" HTTP header that points to + the created subscription resource. + headers: + Content-Type: + description: > + The MIME type of the body of the request. Reference: IETF RFC + 7231 + type: string + maximum: 1 + minimum: 1 + Location: + description: The resource URI of the created VNF instance + type: string + format: url + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + type: string + maximum: 1 + minimum: 0 + schema: + type: array + items: + description: > + This type represents a subscription related to notifications + about VNF indicator value changes. + type: object + required: + - id + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + filter: + description: > + This type represents a subscription filter related to + notifications about VNF indicator value changes. At a + particular nesting level in the filter structure, the + following applies: All attributes shall match in order for + the filter to match (logical "and" between different filter + attributes). If an attribute is an array, the attribute + shall match if at least one of the values in the array + matches (logical "or" between the values of one filter + attribute). + type: object + properties: + vnfInstanceSubscriptionFilter: + description: > + This type represents subscription filter criteria to + match VNF instances. + type: object + properties: + vnfdIds: + description: > + If present, match VNF instances that were created + based on a VNFD identified by one of the vnfdId + values listed in this attribute. The attributes + "vnfdIds" and "vnfProductsFromProviders" are + alternatives to reference to VNF instances that are + based on certain VNFDs in a filter. They should not + be used both in the same filter instance, but one + alternative should be chosen. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProductsFromProviders: + description: > + If present, match VNF instances that belong to VNF + products from certain providers. The attributes + "vnfdIds" and "vnfProductsFromProviders" are + alternatives to reference to VNF instances that are + based on certain VNFDs in a filter. They should not + be used both in the same filter instance, but one + alternative should be chosen. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + Name of the VNF provider to match. + type: string + vnfProducts: + description: > + If present, match VNF instances that belong to + VNF products with certain product names, from + one particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + Name of the VNF product to match. + type: string + versions: + description: > + If present, match VNF instances that + belong to VNF products with certain + versions and a certain product name, + from one particular provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF instances that + belong to VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfInstanceIds: + description: > + If present, match VNF instances with an instance + identifier listed in this attribute. The attributes + "vnfInstanceIds" and "vnfInstanceNames" are + alternatives to reference to particular VNF + Instances in a filter. They should not be used both + in the same filter instance, but one alternative + should be chosen. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceNames: + description: > + If present, match VNF instances with a VNF Instance + Name listed in this attribute. The attributes + "vnfInstanceIds" and "vnfInstanceNames" are + alternatives to reference to particular VNF + Instances in a filter. They should not be used both + in the same filter instance, but one alternative + should be chosen. + type: array + items: + type: string + indicatorIds: + description: | + Match particular VNF indicator identifiers. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + callbackUri: + description: | + The URI of the endpoint to send the notification to. + type: string + format: url + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: | + This type represents a link to a resource. + type: object + required: + - href + properties: + href: + description: | + URI of the referenced resource. + type: string + format: url + '303': + description: > + See Other + + A subscription with the same callbackURI and the same filter already + exists and the policy of the VNFM is to not create redundant + subscriptions. The HTTP response shall include a "Location" HTTP + header that contains the resource URI of the existing subscription + resource. The response body shall be empty. + '400': + description: > + Bad Request + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or a syntactically + incorrect payload body), the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided, and + should include in the "detail" attribute more information about the + source of the problem. If the request contains a malformed access + token, the API producer should respond with this response. The + details of the error shall be returned in the WWW-Authenticate HTTP + header, as defined in IETF RFC 6750 and IETF RFC 7235. The + ProblemDetails structure may be provided. If there is an application + error related to the client's input that cannot be easily mapped to + any other HTTP response code ("catch all error"), the API producer + shall respond with this response code.The "ProblemDetails" structure + shall be provided, and shall include in the "detail" attribute more + information about the source of the problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + type: string + maximum: 1 + minimum: 0 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '401': + description: > + Unauthorized + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + type: string + maximum: 1 + minimum: 0 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '403': + description: > + Forbidden + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '405': + description: > + Method Not Allowed + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted in that case. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '406': + description: > + Not Acceptable + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted in that case. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '500': + description: > + Internal Server Error + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond withthis response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '503': + description: > + Service Unavailable + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 [13] for + the use of the "Retry-After" HTTP header and for the alternative to + refuse the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + get: + description: > + Query Subscription Information + + + The GET method queries the list of active subscriptions of the + functional block that invokes the method. It can be used e.g. for + resynchronization after error situations. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231 + in: header + required: true + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235 + in: header + required: false + type: string + responses: + '200': + description: > + OK + + The list of subscriptions was queried successfully. The response + body shall contain the representations of all active subscriptions + of the functional block that invokes the method which match the + attribute filter. + headers: + Content-Type: + description: > + The MIME type of the body of the request. Reference: IETF RFC + 7231 + type: string + maximum: 1 + minimum: 1 + Location: + description: The resource URI of the created VNF instance + type: string + format: url + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + type: string + maximum: 1 + minimum: 0 + schema: + type: array + items: + description: > + This type represents a subscription related to notifications + about VNF indicator value changes. + type: object + required: + - id + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + filter: + description: > + This type represents a subscription filter related to + notifications about VNF indicator value changes. At a + particular nesting level in the filter structure, the + following applies: All attributes shall match in order for + the filter to match (logical "and" between different filter + attributes). If an attribute is an array, the attribute + shall match if at least one of the values in the array + matches (logical "or" between the values of one filter + attribute). + type: object + properties: + vnfInstanceSubscriptionFilter: + description: > + This type represents subscription filter criteria to + match VNF instances. + type: object + properties: + vnfdIds: + description: > + If present, match VNF instances that were created + based on a VNFD identified by one of the vnfdId + values listed in this attribute. The attributes + "vnfdIds" and "vnfProductsFromProviders" are + alternatives to reference to VNF instances that are + based on certain VNFDs in a filter. They should not + be used both in the same filter instance, but one + alternative should be chosen. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProductsFromProviders: + description: > + If present, match VNF instances that belong to VNF + products from certain providers. The attributes + "vnfdIds" and "vnfProductsFromProviders" are + alternatives to reference to VNF instances that are + based on certain VNFDs in a filter. They should not + be used both in the same filter instance, but one + alternative should be chosen. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + Name of the VNF provider to match. + type: string + vnfProducts: + description: > + If present, match VNF instances that belong to + VNF products with certain product names, from + one particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + Name of the VNF product to match. + type: string + versions: + description: > + If present, match VNF instances that + belong to VNF products with certain + versions and a certain product name, + from one particular provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF instances that + belong to VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfInstanceIds: + description: > + If present, match VNF instances with an instance + identifier listed in this attribute. The attributes + "vnfInstanceIds" and "vnfInstanceNames" are + alternatives to reference to particular VNF + Instances in a filter. They should not be used both + in the same filter instance, but one alternative + should be chosen. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceNames: + description: > + If present, match VNF instances with a VNF Instance + Name listed in this attribute. The attributes + "vnfInstanceIds" and "vnfInstanceNames" are + alternatives to reference to particular VNF + Instances in a filter. They should not be used both + in the same filter instance, but one alternative + should be chosen. + type: array + items: + type: string + indicatorIds: + description: | + Match particular VNF indicator identifiers. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + callbackUri: + description: | + The URI of the endpoint to send the notification to. + type: string + format: url + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: | + This type represents a link to a resource. + type: object + required: + - href + properties: + href: + description: | + URI of the referenced resource. + type: string + format: url + '400': + description: > + Bad Request + + Invalid attribute-based filtering parameters or Invalid attribute + selector. It fhe request is malformed or syntactically incorrect + (e.g. if the request URI contains incorrect query parameters or a + syntactically incorrect payload body), the API producer shall + respond with this response code. The "ProblemDetails" structure + shall be provided, and should include in the "detail" attribute more + information about the source of the problem. If the request contains + a malformed access token, the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. If there is + an application error related to the client's input that cannot be + easily mapped to any other HTTP response code ("catch all error"), + the API producer shall respond with this response code.The + "ProblemDetails" structure shall be provided, and shall include in + the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + type: string + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '401': + description: > + Unauthorized + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + type: string + maximum: 1 + minimum: 0 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '403': + description: > + Forbidden + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '405': + description: > + Method Not Allowed + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted in that case. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '406': + description: > + Not Acceptable + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted in that case. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '500': + description: > + Internal Server Error + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond withthis response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '503': + description: > + Service Unavailable + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 [13] for + the use of the "Retry-After" HTTP header and for the alternative to + refuse the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '/indicators/subscriptions/{subscriptionId}': + parameters: + - name: subscriptionId + description: > + Identifier of this subscription. This identifier can be retrieved from + the resource referenced by the "Location" HTTP header in the response + to a POST request creating a new subscription resource. It can also be + retrieved from the "id" attribute in the payload body of that + response. + in: path + type: string + required: true + get: + description: | + Query Subscription Information + + The GET method reads an individual subscription. + parameters: + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231 + in: header + required: true + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235 + in: header + required: false + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + type: string + responses: + '200': + description: > + OK + + The operation has completed successfully. The response body shall + contain a representation of the subscription resource. + headers: + Content-Type: + description: > + The MIME type of the body of the request. Reference: IETF RFC + 7231 + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + type: string + maximum: 1 + minimum: 0 + schema: + description: > + This type represents a subscription related to notifications about + VNF indicator value changes. + type: object + required: + - id + - callbackUri + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + filter: + description: > + This type represents a subscription filter related to + notifications about VNF indicator value changes. At a + particular nesting level in the filter structure, the + following applies: All attributes shall match in order for the + filter to match (logical "and" between different filter + attributes). If an attribute is an array, the attribute shall + match if at least one of the values in the array matches + (logical "or" between the values of one filter attribute). + type: object + properties: + vnfInstanceSubscriptionFilter: + description: > + This type represents subscription filter criteria to match + VNF instances. + type: object + properties: + vnfdIds: + description: > + If present, match VNF instances that were created + based on a VNFD identified by one of the vnfdId values + listed in this attribute. The attributes "vnfdIds" and + "vnfProductsFromProviders" are alternatives to + reference to VNF instances that are based on certain + VNFDs in a filter. They should not be used both in the + same filter instance, but one alternative should be + chosen. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfProductsFromProviders: + description: > + If present, match VNF instances that belong to VNF + products from certain providers. The attributes + "vnfdIds" and "vnfProductsFromProviders" are + alternatives to reference to VNF instances that are + based on certain VNFDs in a filter. They should not be + used both in the same filter instance, but one + alternative should be chosen. + type: array + items: + type: object + required: + - vnfProvider + properties: + vnfProvider: + description: | + Name of the VNF provider to match. + type: string + vnfProducts: + description: > + If present, match VNF instances that belong to + VNF products with certain product names, from + one particular provider. + type: array + items: + type: object + required: + - vnfProductName + properties: + vnfProductName: + description: | + Name of the VNF product to match. + type: string + versions: + description: > + If present, match VNF instances that + belong to VNF products with certain + versions and a certain product name, from + one particular provider. + type: array + items: + type: object + required: + - vnfSoftwareVersion + properties: + vnfSoftwareVersion: + description: | + A version. + type: string + vnfdVersions: + description: > + If present, match VNF instances that + belong to VNF products with certain VNFD + versions, a certain software version and + a certain product name, from one + particular provider. + type: array + items: + description: | + A version. + type: string + vnfInstanceIds: + description: > + If present, match VNF instances with an instance + identifier listed in this attribute. The attributes + "vnfInstanceIds" and "vnfInstanceNames" are + alternatives to reference to particular VNF Instances + in a filter. They should not be used both in the same + filter instance, but one alternative should be chosen. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + vnfInstanceNames: + description: > + If present, match VNF instances with a VNF Instance + Name listed in this attribute. The attributes + "vnfInstanceIds" and "vnfInstanceNames" are + alternatives to reference to particular VNF Instances + in a filter. They should not be used both in the same + filter instance, but one alternative should be chosen. + type: array + items: + type: string + indicatorIds: + description: | + Match particular VNF indicator identifiers. + type: array + items: + description: | + An identifier that is unique within a VNF descriptor. + type: string + callbackUri: + description: | + The URI of the endpoint to send the notification to. + type: string + format: url + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: | + This type represents a link to a resource. + type: object + required: + - href + properties: + href: + description: | + URI of the referenced resource. + type: string + format: url + '400': + description: > + Bad Request + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or a syntactically + incorrect payload body), the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided, and + should include in the "detail" attribute more information about the + source of the problem. If the request contains a malformed access + token, the API producer should respond with this response. The + details of the error shall be returned in the WWW-Authenticate HTTP + header, as defined in IETF RFC 6750 and IETF RFC 7235. The + ProblemDetails structure may be provided. If there is an application + error related to the client's input that cannot be easily mapped to + any other HTTP response code ("catch all error"), the API producer + shall respond with this response code.The "ProblemDetails" structure + shall be provided, and shall include in the "detail" attribute more + information about the source of the problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + type: string + maximum: 1 + minimum: 0 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '401': + description: > + Unauthorized + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + type: string + maximum: 1 + minimum: 0 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '403': + description: > + Forbidden + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '405': + description: > + Method Not Allowed + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted in that case. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '406': + description: > + Not Acceptable + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted in that case. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '500': + description: > + Internal Server Error + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond withthis response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '503': + description: > + Service Unavailable + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 [13] for + the use of the "Retry-After" HTTP header and for the alternative to + refuse the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + delete: + description: | + Terminate Subscription + + The DELETE method terminates an individual subscription. + parameters: + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235 + in: header + required: false + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + type: string + responses: + '204': + description: > + No Content + + The subscription resource was deleted successfully. The response + body shall be empty. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + type: string + maximum: 1 + minimum: 0 + '400': + description: > + Bad Request + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or a syntactically + incorrect payload body), the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided, and + should include in the "detail" attribute more information about the + source of the problem. If the request contains a malformed access + token, the API producer should respond with this response. The + details of the error shall be returned in the WWW-Authenticate HTTP + header, as defined in IETF RFC 6750 and IETF RFC 7235. The + ProblemDetails structure may be provided. If there is an application + error related to the client's input that cannot be easily mapped to + any other HTTP response code ("catch all error"), the API producer + shall respond with this response code.The "ProblemDetails" structure + shall be provided, and shall include in the "detail" attribute more + information about the source of the problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + type: string + maximum: 1 + minimum: 0 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '401': + description: > + Unauthorized + + If the request contains no access token even though one is required, + or if the request contains an authorization token that is invalid + (e.g. expired or revoked), the API producer should respond with this + response. The details of the error shall be returned in the + WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF + RFC 7235. The ProblemDetails structure may be provided. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + type: string + maximum: 1 + minimum: 0 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '403': + description: > + Forbidden + + If the API consumer is not allowed to perform a particular request + to a particular resource, the API producer shall respond with this + response code. The "ProblemDetails" structure shall be provided. It + should include in the "detail" attribute information about the + source of the problem, and may indicate how to solve it. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '405': + description: > + Method Not Allowed + + If a particular HTTP method is not supported for a particular + resource, the API producer shall respond with this response code. + The "ProblemDetails" structure may be omitted in that case. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '406': + description: > + Not Acceptable + + If the "Accept" HTTP header does not contain at least one name of a + content type that is acceptable to the API producer, the API + producer shall respond with this response code. The "ProblemDetails" + structure may be omitted in that case. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '500': + description: > + Internal Server Error + + If there is an application error not related to the client's input + that cannot be easily mapped to any other HTTP response code ("catch + all error"), the API producer shall respond withthis response code. + The "ProblemDetails" structure shall be provided, and shall include + in the "detail" attribute more information about the source of the + problem. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + '503': + description: > + Service Unavailable + + If the API producer encounters an internal overload situation of + itself or of a system it relies on, it should respond with this + response code, following the provisions in IETF RFC 7231 [13] for + the use of the "Retry-After" HTTP header and for the alternative to + refuse the connection. The "ProblemDetails" structure may be + omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + type: string + maximum: 1 + minimum: 1 + schema: + description: > + The definition of the general "ProblemDetails" data structure from + IETF RFC 7807 [19] is reproduced inthis structure. Compared to the + general framework defined in IETF RFC 7807 [19], the "status" and + "detail" attributes are mandated to be included by the present + document, to ensure that the response contains additional textual + information about an error. IETF RFC 7807 [19] foresees + extensibility of the "ProblemDetails" type. It is possible that + particular APIs in the present document, or particular + implementations, define extensions to define additional attributes + that provide more information about the error. The description + column only provides some explanation of the meaning to Facilitate + understanding of the design. For a full description, see IETF RFC + 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that identifies + the problem type. It is encouraged that the URI provides + human-readable documentation for the problem (e.g. using HTML) + when dereferenced. When this member is not present, its value + is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It should + not change from occurrence to occurrence of the problem, + except for purposes of localization. If type is given and + other than "about:blank", this attribute shall also be + provided. A short, human-readable summary of the problem + type. It SHOULD NOT change from occurrence to occurrence of + the problem, except for purposes of localization (e.g., using + proactive content negotiation; see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. The + HTTP status code ([RFC7231], Section 6) generated by the + origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence of + the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of the + problem. It may yield further information if dereferenced. + type: string + format: URI + diff --git a/SOL003/VNFIndicator-API_nxw/Subscriptions.robot b/SOL003/VNFIndicator-API_nxw/Subscriptions.robot new file mode 100644 index 00000000..2db9ed0f --- /dev/null +++ b/SOL003/VNFIndicator-API_nxw/Subscriptions.robot @@ -0,0 +1,161 @@ +*** Settings *** +Library HttpLibrary.HTTP +Library JSONSchemaLibrary schemas/ +Resource environment/generic.txt # Generic Parameters +Resource environment/subscriptions.txt +Library OperatingSystem +Library JSONLibrary + +*** Test Cases *** +GET Subscription + Log Trying to get the list of subscriptions + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + GET ${apiRoot}/${apiName}/${apiVersion}/subscriptions + Response Status Code Should Equal 200 + Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} + Log Received a 200 OK as expected + ${result}= Get Response Body + ${json}= evaluate json.loads('''${result}''') json + Validate Json VnfIndicatorSubscription.schema.json ${json} + Log Validated VnfIndicatorSubscription schema + +GET Subscription - Filter + Log Trying to get the list of subscriptions using filters + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + GET ${apiRoot}/${apiName}/${apiVersion}/subscriptions?${POS_FILTER} + Response Status Code Should Equal 200 + Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} + Log Received a 200 OK as expected + ${result}= Get Response Body + ${json}= evaluate json.loads('''${result}''') json + Validate Json VnfIndicatorSubscriptions.schema.json ${json} + Log Validated VnfIndicatorSubscriptions schema + +GET Subscription - Negative Filter + Log Trying to get the list of subscriptions using filters with wrong attribute name + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + GET ${apiRoot}/${apiName}/${apiVersion}/subscriptions?${NEG_FILTER} + Response Status Code Should Equal 400 + Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} + Log Received a 400 Bad Request as expected + ${problemDetails}= Get Response Body + ${json}= evaluate json.loads('''${problemDetails}''') json + Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} + Log Trying to validate ProblemDetails + Validate Json ProblemDetails.schema.json ${json} + Log Validation OK + +GET Subscription - Negative (Not Found) + Log Trying to perform a request on a Uri which doesn't exist + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + GET ${apiRoot}/${apiName}/${apiVersion}/subscription + Response Status Code Should Equal 404 + Log Received 404 Not Found as expected + ${problemDetails}= Get Response Body + ${json}= evaluate json.loads('''${problemDetails}''') json + Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} + Log Trying to validate ProblemDetails + Validate Json ProblemDetails.schema.json ${json} + Log Validation OK + +GET Subscription - Negative (Unauthorized: Wrong Token) + Log Trying to perform a negative get, using wrong authorization bearer + Pass Execution If ${VNFM_AUTH_USAGE} == 0 Skipping test as VNFM is not supporting authentication + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + GET ${apiRoot}/${apiName}/${apiVersion}/subscriptions + Response Status Code Should Equal 401 + Log Received 401 Unauthorized as expected + ${problemDetails}= Get Response Body + ${json}= evaluate json.loads('''${problemDetails}''') json + Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} + Log Trying to validate ProblemDetails + Validate Json ProblemDetails.schema.json ${json} + Log Validation OK + +POST Subscription + Log Trying to create a new subscription + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Set Request Header Content-Type ${CONTENT_TYPE_JSON} + ${body}= Get File json/subscriptions.json + Set Request Body ${body} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + POST ${apiRoot}/${apiName}/${apiVersion}/subscriptions + Response Status Code Should Equal 201 + Log Received 201 Created as expected + Response Should Have Header Location + Log Response has header Location + ${result}= Get Response Body + ${json}= evaluate json.loads('''${result}''') json + Validate Json VnfIndicatorSubscriptions.schema.json ${json} + Log Validation of VnfIndicatorSubscription OK + +POST Subscription - DUPLICATION + Log Trying to create a subscription with an already created content + Pass Execution If ${VNFM_DUPLICATION} == 0 VNFM is not permitting duplication. Skipping the test + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Set Request Header Content-Type ${CONTENT_TYPE_JSON} + ${body}= Get File json/subscriptions.json + Set Request Body ${body} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + POST ${apiRoot}/${apiName}/${apiVersion}/subscriptions + Response Status Code Should Equal 201 + Log Received 201 Created as expected + Response Should Have Header Location + Log Response has header Location + ${result} Get Response Body + ${json}= evaluate json.loads('''${result}''') json + Validate Json VnfIndictorSubscriptions.schema.json ${json} + Log Validation of VnfIndicatorSubscriptions OK + +POST Subscription - NO DUPLICATION + Log Trying to create a subscription with an already created content + Pass Execution If ${VNFM_DUPLICATION} == 1 VNFM is permitting duplication. Skipping the test + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Set Request Header Content-Type ${CONTENT_TYPE_JSON} + ${body}= Get File json/subscriptions.json + Set Request Body ${body} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + POST ${apiRoot}/${apiName}/${apiVersion}/subscriptions + Response Status Code Should Equal 303 + Log Received 303 See Other as expected + Response Should Have Header Location + Log Response header contains Location + +PUT Subscription - (Method not implemented) + Log Trying to perform a PUT. This method should not be implemented + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + PUT ${apiRoot}/${apiName}/${apiVersion}/subscriptions + Response Status Code Should Equal 405 + Log Received 405 Method not implemented as expected + +PATCH Subscription - (Method not implemented) + Log Trying to perform a PATCH. This method should not be implemented + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + Http Request PATCH ${apiRoot}/${apiName}/${apiVersion}/subscriptions + Response Status Code Should Equal 405 + Log Received 405 Method not implemented as expected + +DELETE Subscription - (Method not implemented) + Log Trying to perform a DELETE. This method should not be implemented + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + DELETE ${apiRoot}/${apiName}/${apiVersion}/subscriptions + Response Status Code Should Equal 405 + Log Received 405 Method not implemented as expected diff --git a/SOL003/VNFIndicator-API_nxw/VNFIndicators.robot b/SOL003/VNFIndicator-API_nxw/VNFIndicators.robot new file mode 100644 index 00000000..84e41824 --- /dev/null +++ b/SOL003/VNFIndicator-API_nxw/VNFIndicators.robot @@ -0,0 +1,132 @@ +*** Settings *** +Library HttpLibrary.HTTP +Library JSONSchemaLibrary schemas/ +Resource environment/generic.txt # Generic Parameters +Library JSONLibrary +Resource environment/vnfIndicators.txt + +*** Test Cases *** +GET all Indicators + Log The GET method queries multiple VNF indicators + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + GET ${apiRoot}/${apiName}/${apiVersion}/indicators + Response Status Code Should Equal 200 + ${result}= Get Response Body + ${json}= evaluate json.loads('''${result}''') json + Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} + Log Trying to validate response + Validate Json vnfIndicators.schema.json ${json} + Log Validation OK + +GET all Indicators - Filter + Log The GET method queries multiple VNF indicators using Attribute-based filtering parameters + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + GET ${apiRoot}/${apiName}/${apiVersion}/indicators?${POS_FIELDS} + Response Status Code Should Equal 200 + ${result}= Get Response Body + ${json}= evaluate json.loads('''${result}''') json + Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} + Log Trying to validate response + Validate Json vnfIndicators.schema.json ${json} + Log Validation OK + +GET all Indicators - Negative (wronge filter name) + Log The GET method queries multiple VNF indicators using Attribute-based filtering parameters. Negative case, with erroneous attribute name + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + GET ${apiRoot}/${apiName}/${apiVersion}/indicators?${NEG_FIELDS} + Response Status Code Should Equal 400 + Log Received 400 Bad Request as expected + ${problemDetails}= Get Response Body + ${json}= evaluate json.loads('''${problemDetails}''') json + Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} + Log Trying to validate ProblemDetails + Validate Json ProblemDetails.schema.json ${json} + Log Validation OK + +GET all Indicators - Negative (Unauthorized: Wrong Token) + Log Trying to perform a negative get, using wrong authorization bearer + Pass Execution If ${VNFM_AUTH_USAGE} == 0 Skipping test as NFVO is not supporting authentication + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Set Request Header Authorization ${NEG_AUTHORIZATION} + GET ${apiRoot}/${apiName}/${apiVersion}/indicators + Response Status Code Should Equal 401 + Log Received 401 Unauthorized as expected + ${problemDetails}= Get Response Body + ${json}= evaluate json.loads('''${problemDetails}''') json + Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} + Log Trying to validate ProblemDetails + Validate Json ProblemDetails.schema.json ${json} + Log Validation OK + +GET all Indicators - Negative (Unauthorized: No Token) + Log Trying to perform a negative get, using wrong authorization bearer + Pass Execution If ${VNFM_AUTH_USAGE} == 0 Skipping test as NFVO is not supporting authentication + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Set Request Header Authorization ${NEG_AUTHORIZATION} + GET ${apiRoot}/${apiName}/${apiVersion}/indicators + Response Status Code Should Equal 401 + Log Received 401 Unauthorized as expected + ${problemDetails}= Get Response Body + ${json}= evaluate json.loads('''${problemDetails}''') json + Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} + Log Trying to validate ProblemDetails + Validate Json ProblemDetails.schema.json ${json} + Log Validation OK + +GET all Indicators (Negative: Not found) + Log Trying to perform a GET on a erroneous URI + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + GET ${apiRoot}/${apiName}/${apiVersion}/indicator + Response Status Code Should Equal 404 + Log Received 404 Not Found as expected + ${problemDetails}= Get Response Body + Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} + Log Trying to validate ProblemDetails + Validate Json ProblemDetails.schema.json ${problemDetails} + Log Validation OK + +POST all Indicators (Method not implemented) + Log Trying to perform a POST (method should not be implemented) + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + POST ${apiRoot}/${apiName}/${apiVersion}/indicators + Response Status Code Should Equal 405 + Log Received 405 Method not implemented as expected + +PUT all Indicators (Method not implemented) + Log Trying to perform a PUT. This method should not be implemented + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + PUT ${apiRoot}/${apiName}/${apiVersion}/indicators + Response Status Code Should Equal 405 + Log Received 405 Method not implemented as expected + +PATCH all Indicators (Method not implemented) + Log Trying to perform a PUT. This method should not be implemented + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + Http Request PATCH ${apiRoot}/${apiName}/${apiVersion}/indicators + Response Status Code Should Equal 405 + Log Received 405 Method not implemented as expected + +DELETE all Indicators (Method not implemented) + Log Trying to perform a PUT. This method should not be implemented + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + DELETE ${apiRoot}/${apiName}/${apiVersion}/indicators + Response Status Code Should Equal 405 + Log Received 405 Method not implemented as expected diff --git a/SOL003/VNFIndicator-API_nxw/VnfIndicatorsInVnfInstanceId.robot b/SOL003/VNFIndicator-API_nxw/VnfIndicatorsInVnfInstanceId.robot new file mode 100644 index 00000000..d67c8ade --- /dev/null +++ b/SOL003/VNFIndicator-API_nxw/VnfIndicatorsInVnfInstanceId.robot @@ -0,0 +1,131 @@ +*** Settings *** +Library HttpLibrary.HTTP +Library JSONSchemaLibrary schemas/ +Resource environment/generic.txt # Generic Parameters +Resource environment/vnfIndicatorinVnfInstance.txt +Library JSONLibrary + +*** Test Cases *** +GET Indicators on VNF Instance + Log This resource represents VNF indicators related to a VNF instance. + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + GET ${apiRoot}/${apiName}/${apiVersion}/indicators/${vnfInstanceId} + Response Status Code Should Equal 200 + ${result}= Get Response Body + ${json}= evaluate json.loads('''${result}''') json + Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} + Log Trying to validate response + Validate Json vnfIndicators.schema.json ${json} + Log Validation OK + +GET Indicators on VNF Instance - Filter + Log This resource represents VNF indicators related to a VNF instance. + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + GET ${apiRoot}/${apiName}/${apiVersion}/indicators/${vnfInstanceId}?${POS_FIELDS} + Response Status Code Should Equal 200 + ${result}= Get Response Body + ${json}= evaluate json.loads('''${result}''') json + Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} + Log Trying to validate response + Validate Json vnfIndicators.schema.json ${json} + Log Validation OK + +GET Indicators on VNF Instance - Negative Filter + Log This resource represents VNF indicators related to a VNF instance. + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + GET ${apiRoot}/${apiName}/${apiVersion}/indicators/${vnfInstanceId}?${NEG_FIELDS} + Response Status Code Should Equal 400 + ${problemDetails}= Get Response Body + ${json}= evaluate json.loads('''${problemDetails}''') json + Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} + Log Trying to validate ProblemDetails + Validate Json ProblemDetails.schema.json ${json} + Log Validation OK + +GET Indicators on VNF Instance - Negative (Not Found) + Log Trying to perform a negative get, using wrong authorization bearer + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + GET ${apiRoot}/${apiName}/${apiVersion}/indicators/${erroneousVnfInstanceId} + Response Status Code Should Equal 404 + Log Received 404 Not Found as expected + ${problemDetails}= Get Response Body + ${json}= evaluate json.loads('''${problemDetails}''') json + Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} + Log Trying to validate ProblemDetails + Validate Json ProblemDetails.schema.json ${json} + Log Validation OK + +GET Indicators on VNF Instancee - Negative (Unauthorized: Wrong Token) + Log Trying to perform a negative get, using wrong authorization bearer + Pass Execution If ${VNFM_AUTH_USAGE} == 0 Skipping test as NFVO is not supporting authentication + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Set Request Header Authorization ${NEG_AUTHORIZATION} + GET ${apiRoot}/${apiName}/${apiVersion}/indicators/${vnfInstanceId} + Response Status Code Should Equal 401 + Log Received 401 Unauthorized as expected + ${problemDetails}= Get Response Body + ${json}= evaluate json.loads('''${problemDetails}''') json + Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} + Log Trying to validate ProblemDetails + Validate Json ProblemDetails.schema.json ${json} + Log Validation OK + +GET Indicators on VNF Instance - Negative (Unauthorized: No Token) + Log Trying to perform a negative get, without authentication token. + Pass Execution If ${VNFM_AUTH_USAGE} == 0 Skipping test as NFVO is not supporting authentication + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + GET ${apiRoot}/${apiName}/${apiVersion}/indicators/${vnfInstanceId} + Response Status Code Should Equal 401 + Log Received 401 Unauthorized as expected + ${problemDetails}= Get Response Body + ${json}= evaluate json.loads('''${problemDetails}''') json + Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} + Log Trying to validate ProblemDetails + Validate Json ProblemDetails.schema.json ${json} + Log Validation OK + +POST Indicators on VNF Instance - (Method not implemented) + Log Trying to perform a POST (method should not be implemented) + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + POST ${apiRoot}/${apiName}/${apiVersion}/indicators/${vnfInstanceId} + Response Status Code Should Equal 405 + Log Received 405 Method not implemented as expected + +PUT Indicators on VNF Instance - (Method not implemented) + Log Trying to perform a PUT. This method should not be implemented + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + PUT ${apiRoot}/${apiName}/${apiVersion}/indicators/${vnfInstanceId} + Response Status Code Should Equal 405 + Log Received 405 Method not implemented as expected + +PATCH Indicators on VNF Instance - (Method not implemented) + Log Trying to perform a PATCH. This method should not be implemented + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + Http Request PATCH ${apiRoot}/${apiName}/${apiVersion}/indicators/${vnfInstanceId} + Response Status Code Should Equal 405 + Log Received 405 Method not implemented as expected + +DELETE Indicators on VNF Instance - (Method not implemented) + Log Trying to perform a DELETE. This method should not be implemented + Create HTTP Context ${VNFM_HOST}:${VNFM_PORT} ${VNFM_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${VNFM_AUTH_USAGE} == 1 Set Request Header Authorization ${VNFM_AUTHENTICATION} + DELETE ${apiRoot}/${apiName}/${apiVersion}/indicators/${vnfInstanceId} + Response Status Code Should Equal 405 + Log Received 405 Method not implemented as expected diff --git a/SOL003/VNFIndicator-API_nxw/environment/generic.txt b/SOL003/VNFIndicator-API_nxw/environment/generic.txt new file mode 100644 index 00000000..59e710e4 --- /dev/null +++ b/SOL003/VNFIndicator-API_nxw/environment/generic.txt @@ -0,0 +1,18 @@ +*** Variables *** +${VNFM_HOST} localhost # Hostname of the VNFM +${VNFM_PORT} 8080 # Listening port of the VNFM +${NFVO_HOST} localhost # Hostname of the NFVO +${NFVO_PORT} 8081 # Listening port of the NFVO +${VNFM_SCHEMA} https +${NFVO_SCHEMA} https +${AUTHORIZATION} Bearer 0b79bab50daca910b000d4f1a2b675d604257e42 +${CONTENT_TYPE_JSON} application/json +${ACCEPT_JSON} application/json +${apiRoot} / +${AUTH_USAGE} 1 +${NEG_AUTHORIZATION} Bearer negativetoken +${apiVersion} v1 +${apiName} vnfind +${FIELD_USAGE} 1 +${VNFM_AUTHENTICATION} Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 +${VNFM_AUTH_USAGE} 1 diff --git a/SOL003/VNFIndicator-API_nxw/environment/individualSubscription.txt b/SOL003/VNFIndicator-API_nxw/environment/individualSubscription.txt new file mode 100644 index 00000000..23ed0f47 --- /dev/null +++ b/SOL003/VNFIndicator-API_nxw/environment/individualSubscription.txt @@ -0,0 +1,3 @@ +*** Variables *** +${subscriptionId} f3ae6df7-07e1-47c9-8924-9ebe10343586 +${erroneousSubscriptionId} 442e3ee5-0499-4849-9b31-eb91ce1638f1 # Not existing ID on the subscriptions diff --git a/SOL003/VNFIndicator-API_nxw/environment/individualVnfIndicator.txt b/SOL003/VNFIndicator-API_nxw/environment/individualVnfIndicator.txt new file mode 100644 index 00000000..d5dbf638 --- /dev/null +++ b/SOL003/VNFIndicator-API_nxw/environment/individualVnfIndicator.txt @@ -0,0 +1,4 @@ +*** Variables *** +${vnfInstanceId} 80b0deba-c398-445b-bef0-ac0fe733e3d0 +${indicatorId} 34e70855-a9d3-4fef-aece-76a3cd266ec8 +${erroneousIndicatorId} erroneousIndicatorId diff --git a/SOL003/VNFIndicator-API_nxw/environment/subscriptions.txt b/SOL003/VNFIndicator-API_nxw/environment/subscriptions.txt new file mode 100644 index 00000000..3eb525f4 --- /dev/null +++ b/SOL003/VNFIndicator-API_nxw/environment/subscriptions.txt @@ -0,0 +1,7 @@ +*** Variables *** +${vnfInstanceId} 80b0deba-c398-445b-bef0-ac0fe733e3d0 +${indicatorId} 34e70855-a9d3-4fef-aece-76a3cd266ec8 +${erroneousIndicatorId} erroneousIndicatorId +${POS_FILTER} callbackUri=http://127.0.0.1/subscribe +${NEG_FILTER} callback=http://127.0.0.1/subscribe +${VNFM_DUPLICATION} 1 diff --git a/SOL003/VNFIndicator-API_nxw/environment/vnfIndicatorinVnfInstance.txt b/SOL003/VNFIndicator-API_nxw/environment/vnfIndicatorinVnfInstance.txt new file mode 100644 index 00000000..13ef83d6 --- /dev/null +++ b/SOL003/VNFIndicator-API_nxw/environment/vnfIndicatorinVnfInstance.txt @@ -0,0 +1,5 @@ +*** Variables *** +${vnfInstanceId} 80b0deba-c398-445b-bef0-ac0fe733e3d0 +${erroneousVnfInstanceId} erroneousVnfInstanceId +${POS_FIELDS} name=vnfIndicator +${NEG_FIELDS} wrongName=any_value diff --git a/SOL003/VNFIndicator-API_nxw/environment/vnfIndicators.txt b/SOL003/VNFIndicator-API_nxw/environment/vnfIndicators.txt new file mode 100644 index 00000000..626c660f --- /dev/null +++ b/SOL003/VNFIndicator-API_nxw/environment/vnfIndicators.txt @@ -0,0 +1,3 @@ +*** Variables *** +${POS_FIELDS} name=vnfIndicator&vnfInstanceId=80b0deba-c398-445b-bef0-ac0fe733e3d0 +${NEG_FIELDS} wrongName=wrongValue diff --git a/SOL003/VNFIndicator-API_nxw/jsons/subscriptios.json b/SOL003/VNFIndicator-API_nxw/jsons/subscriptios.json new file mode 100644 index 00000000..ccf9f514 --- /dev/null +++ b/SOL003/VNFIndicator-API_nxw/jsons/subscriptios.json @@ -0,0 +1,3 @@ +{ + "callbackUri": "http://127.0.0.1/subscribe" +} \ No newline at end of file diff --git a/SOL003/VNFIndicator-API_nxw/schemas/VnfIndicatorSubscription.schema.json b/SOL003/VNFIndicator-API_nxw/schemas/VnfIndicatorSubscription.schema.json new file mode 100644 index 00000000..987c0d71 --- /dev/null +++ b/SOL003/VNFIndicator-API_nxw/schemas/VnfIndicatorSubscription.schema.json @@ -0,0 +1 @@ +{ "type": "array", "items": { "description": "This type represents a subscription related to notifications about VNF indicator value changes.\n", "type": "object", "required": [ "id", "callbackUri", "_links" ], "properties": { "id": { "description": "An identifier with the intention of being globally unique.\n", "type": "string" }, "filter": { "description": "This type represents a subscription filter related to notifications about VNF indicator value changes. At a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\n", "type": "object", "properties": { "vnfInstanceSubscriptionFilter": { "description": "This type represents subscription filter criteria to match VNF instances.\n", "type": "object", "properties": { "vnfdIds": { "description": "If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. The attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances that are based on certain VNFDs in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.\n", "type": "array", "items": { "description": "An identifier with the intention of being globally unique.\n", "type": "string" } }, "vnfProductsFromProviders": { "description": "If present, match VNF instances that belong to VNF products from certain providers. The attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances that are based on certain VNFDs in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.\n", "type": "array", "items": { "type": "object", "required": [ "vnfProvider" ], "properties": { "vnfProvider": { "description": "Name of the VNF provider to match.\n", "type": "string" }, "vnfProducts": { "description": "If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n", "type": "array", "items": { "type": "object", "required": [ "vnfProductName" ], "properties": { "vnfProductName": { "description": "Name of the VNF product to match.\n", "type": "string" }, "versions": { "description": "If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n", "type": "array", "items": { "type": "object", "required": [ "vnfSoftwareVersion" ], "properties": { "vnfSoftwareVersion": { "description": "A version.\n", "type": "string" }, "vnfdVersions": { "description": "If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n", "type": "array", "items": { "description": "A version.\n", "type": "string" } } } } } } } } } } }, "vnfInstanceIds": { "description": "If present, match VNF instances with an instance identifier listed in this attribute. The attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF Instances in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.\n", "type": "array", "items": { "description": "An identifier with the intention of being globally unique.\n", "type": "string" } }, "vnfInstanceNames": { "description": "If present, match VNF instances with a VNF Instance Name listed in this attribute. The attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF Instances in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.\n", "type": "array", "items": { "type": "string" } } } }, "indicatorIds": { "description": "Match particular VNF indicator identifiers.\n", "type": "array", "items": { "description": "An identifier that is unique within a VNF descriptor.\n", "type": "string" } } } }, "callbackUri": { "description": "The URI of the endpoint to send the notification to.\n", "type": "string", "format": "url" }, "_links": { "description": "Links for this resource.\n", "type": "object", "required": [ "self" ], "properties": { "self": { "description": "This type represents a link to a resource.\n", "type": "object", "required": [ "href" ], "properties": { "href": { "description": "URI of the referenced resource.\n", "type": "string", "format": "url" } } } } } } }} \ No newline at end of file diff --git a/SOL003/VNFIndicator-API_nxw/schemas/vnfIndicators.schema.json b/SOL003/VNFIndicator-API_nxw/schemas/vnfIndicators.schema.json new file mode 100644 index 00000000..7aae0e6d --- /dev/null +++ b/SOL003/VNFIndicator-API_nxw/schemas/vnfIndicators.schema.json @@ -0,0 +1 @@ +{ "type": "array", "items": { "description": "This type represents a VNF indicator value.\n", "type": "object", "required": [ "id", "value", "vnfInstanceId", "_links" ], "properties": { "id": { "description": "An identifier that is unique within a VNF descriptor.\n", "type": "string" }, "name": { "description": "Human readable name of the indicator. Shall be present if defined in the VNFD.\n", "type": "string" }, "value": { "description": "Provides the value of the indicator. The value format is defined in the VNFD. ETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.\n", "type": "object" }, "vnfInstanceId": { "description": "An identifier with the intention of being globally unique.\n", "type": "string" }, "_links": { "description": "Links for this resource.\n", "type": "object", "required": [ "self", "vnfInstance" ], "properties": { "self": { "description": "This type represents a link to a resource.\n", "type": "object", "required": [ "href" ], "properties": { "href": { "description": "URI of the referenced resource.\n", "type": "string", "format": "url" } } }, "vnfInstance": { "description": "This type represents a link to a resource.\n", "type": "object", "required": [ "href" ], "properties": { "href": { "description": "URI of the referenced resource.\n", "type": "string", "format": "url" } } } } } } }} \ No newline at end of file diff --git a/SOL003/VNFPackageManagement-API_nxw/IndividualSubscription.robot b/SOL003/VNFPackageManagement-API_nxw/IndividualSubscription.robot index ee36ae80..fbf646f7 100644 --- a/SOL003/VNFPackageManagement-API_nxw/IndividualSubscription.robot +++ b/SOL003/VNFPackageManagement-API_nxw/IndividualSubscription.robot @@ -4,10 +4,11 @@ Library JSONSchemaLibrary schemas/ Resource environment/generic.txt # Generic Parameters Resource environment/individualSubscription.txt Library OperatingSystem +Library JSONLibrary *** Test Cases *** GET Individual Subscription - Log Trying to get the list of subscriptions + Log Trying to get a single subscription identified by subscriptionId Create HTTP Context ${NFVO_HOST}:${NFVO_PORT} ${NFVO_SCHEMA} Set Request Header Accept ${ACCEPT_JSON} Run Keyword If ${AUTH_USAGE} == 1 Set Request Header Authorization ${AUTHORIZATION} @@ -98,3 +99,12 @@ PATCH Subscription - (Method not implemented) Http Request PATCH ${apiRoot}/${apiName}/${apiVersion}/subscriptions/${subscriptionId} Response Status Code Should Equal 405 Log Received 405 Method not implemented as expected + +POST Subscription - (Method not implemented) + Log Trying to perform a POST. This method should not be implemented + Create HTTP Context ${NFVO_HOST}:${NFVO_PORT} ${NFVO_SCHEMA} + Set Request Header Accept ${ACCEPT_JSON} + Run Keyword If ${AUTH_USAGE} == 1 Set Request Header Authorization ${AUTHORIZATION} + POST ${apiRoot}/${apiName}/${apiVersion}/subscriptions/${subscriptionId} + Response Status Code Should Equal 405 + Log Received 405 Method not implemented as expected diff --git a/SOL003/VNFPackageManagement-API_nxw/IndividualVNFPackage.robot b/SOL003/VNFPackageManagement-API_nxw/IndividualVNFPackage.robot index 5e95a319..2231786a 100644 --- a/SOL003/VNFPackageManagement-API_nxw/IndividualVNFPackage.robot +++ b/SOL003/VNFPackageManagement-API_nxw/IndividualVNFPackage.robot @@ -3,6 +3,7 @@ Library HttpLibrary.HTTP Library JSONSchemaLibrary schemas/ Resource environment/generic.txt # Generic Parameters Resource environment/individualVnfPackage.txt +Library JSONLibrary *** Test Cases *** GET Individual VNF Package diff --git a/SOL003/VNFPackageManagement-API_nxw/Subscriptions.robot b/SOL003/VNFPackageManagement-API_nxw/Subscriptions.robot index 67aed17a..0553bd81 100644 --- a/SOL003/VNFPackageManagement-API_nxw/Subscriptions.robot +++ b/SOL003/VNFPackageManagement-API_nxw/Subscriptions.robot @@ -4,6 +4,7 @@ Library JSONSchemaLibrary schemas/ Resource environment/generic.txt # Generic Parameters Resource environment/subscriptions.txt Library OperatingSystem +Library JSONLibrary *** Test Cases *** GET Subscription diff --git a/SOL003/VNFPackageManagement-API_nxw/VNFDInIndividualVNFPackage.robot b/SOL003/VNFPackageManagement-API_nxw/VNFDInIndividualVNFPackage.robot index 4f19ff4f..7c366fe1 100644 --- a/SOL003/VNFPackageManagement-API_nxw/VNFDInIndividualVNFPackage.robot +++ b/SOL003/VNFPackageManagement-API_nxw/VNFDInIndividualVNFPackage.robot @@ -3,6 +3,7 @@ Library HttpLibrary.HTTP Library JSONSchemaLibrary schemas/ Resource environment/generic.txt # Generic Parameters Resource environment/vnfdInIndividualVnfPackage.txt +Library JSONLibrary *** Test Cases *** GET VNFD in Individual VNF Package (PLAIN/PLAIN) diff --git a/SOL003/VNFPackageManagement-API_nxw/VNFPackageArtifacts.robot b/SOL003/VNFPackageManagement-API_nxw/VNFPackageArtifacts.robot index e7cca221..0381e270 100644 --- a/SOL003/VNFPackageManagement-API_nxw/VNFPackageArtifacts.robot +++ b/SOL003/VNFPackageManagement-API_nxw/VNFPackageArtifacts.robot @@ -3,6 +3,7 @@ Library HttpLibrary.HTTP Library JSONSchemaLibrary schemas/ Resource environment/generic.txt # Generic Parameters Resource environment/vnfPackageArtifacts.txt +Library JSONLibrary *** Test Cases *** GET VNF Package Artifact diff --git a/SOL003/VNFPackageManagement-API_nxw/VNFPackageContent.robot b/SOL003/VNFPackageManagement-API_nxw/VNFPackageContent.robot index bcfbe3ab..58ed1878 100644 --- a/SOL003/VNFPackageManagement-API_nxw/VNFPackageContent.robot +++ b/SOL003/VNFPackageManagement-API_nxw/VNFPackageContent.robot @@ -3,6 +3,7 @@ Library HttpLibrary.HTTP Library JSONSchemaLibrary schemas/ Resource environment/generic.txt # Generic Parameters Resource environment/vnfPackageContent.txt +Library JSONLibrary *** Test Cases *** GET VNF Package Content diff --git a/SOL003/VNFPackageManagement-API_nxw/VNFPackages.robot b/SOL003/VNFPackageManagement-API_nxw/VNFPackages.robot index ac2367e1..7f07ea9d 100644 --- a/SOL003/VNFPackageManagement-API_nxw/VNFPackages.robot +++ b/SOL003/VNFPackageManagement-API_nxw/VNFPackages.robot @@ -138,9 +138,10 @@ GET all PACKAGE (Negative: Not found) Response Status Code Should Equal 404 Log Received 404 Not Found as expected ${problemDetails}= Get Response Body + ${json}= evaluate json.loads('''${problemDetails}''') json Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} Log Trying to validate ProblemDetails - Validate Json ProblemDetails.schema.json ${problemDetails} + Validate Json ProblemDetails.schema.json ${json} Log Validation OK POST all PACKAGE (Method not implemented) @@ -151,11 +152,6 @@ POST all PACKAGE (Method not implemented) POST ${apiRoot}/${apiName}/${apiVersion}/vnf_packages Response Status Code Should Equal 405 Log Received 405 Method not implemented as expected - #${problemDetails}= Get Response Body - #Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} - #Log Trying to validate ProblemDetails - #Validate Json ProblemDetails.schema.json ${problemDetails} - #Log Validation OK PUT all PACKAGE (Method not implemented) Log Trying to perform a PUT. This method should not be implemented @@ -165,26 +161,15 @@ PUT all PACKAGE (Method not implemented) PUT ${apiRoot}/${apiName}/${apiVersion}/vnf_packages Response Status Code Should Equal 405 Log Received 405 Method not implemented as expected - #${problemDetails}= Get Response Body - #Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} - #Log Trying to validate ProblemDetails - #Validate Json ProblemDetails.schema.json ${problemDetails} - #Log Validation OK PATCH all PACKAGE (Method not implemented) Log Trying to perform a PUT. This method should not be implemented Create HTTP Context ${NFVO_HOST}:${NFVO_PORT} ${NFVO_SCHEMA} Set Request Header Accept ${ACCEPT_JSON} Run Keyword If ${AUTH_USAGE} == 1 Set Request Header Authorization ${AUTHORIZATION} - Http Request "PATCH" ${apiRoot}/${apiName}/${apiVersion}/vnf_packages - #PATCH ${apiRoot}/${apiName}/${apiVersion}/vnf_packages + Http Request PATCH ${apiRoot}/${apiName}/${apiVersion}/vnf_packages Response Status Code Should Equal 405 Log Received 405 Method not implemented as expected - #${problemDetails}= Get Response Body - #Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} - #Log Trying to validate ProblemDetails - #Validate Json ProblemDetails.schema.json ${problemDetails} - #Log Validation OK DELETE all PACKAGE (Method not implemented) Log Trying to perform a PUT. This method should not be implemented @@ -194,8 +179,3 @@ DELETE all PACKAGE (Method not implemented) DELETE ${apiRoot}/${apiName}/${apiVersion}/vnf_packages Response Status Code Should Equal 405 Log Received 405 Method not implemented as expected - #${problemDetails}= Get Response Body - #Response Header Should Equal Content-Type ${CONTENT_TYPE_JSON} - #Log Trying to validate ProblemDetails - #Validate Json ProblemDetails.schema.json ${problemDetails} - #Log Validation OK -- GitLab