Update vnfm simulator - subscribe and notify
Change-Id: Iced3da9cbedabba7df9defb4933ec69dfaf75823
Issue-ID: SO-2420
Signed-off-by: AndrewLamb <andrew.a.lamb@est.tech>
diff --git a/plans/so/integration-etsi-testing/so-simulators/pom.xml b/plans/so/integration-etsi-testing/so-simulators/pom.xml
index 372b073..4be20c6 100644
--- a/plans/so/integration-etsi-testing/so-simulators/pom.xml
+++ b/plans/so/integration-etsi-testing/so-simulators/pom.xml
@@ -73,6 +73,12 @@
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
+ <exclusions>
+ <exclusion>
+ <artifactId>android-json</artifactId>
+ <groupId>com.vaadin.external.google</groupId>
+ </exclusion>
+ </exclusions>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
@@ -84,4 +90,4 @@
<version>${jax.ws.rs}</version>
</dependency>
</dependencies>
-</project>
\ No newline at end of file
+</project>
diff --git a/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-api/pom.xml b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-api/pom.xml
index 23dc243..7b8aa27 100644
--- a/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-api/pom.xml
+++ b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-api/pom.xml
@@ -46,6 +46,47 @@
</configOptions>
</configuration>
</execution>
+ <execution>
+ <id>sol003-packagemanagement-notification-api</id>
+ <goals>
+ <goal>generate</goal>
+ </goals>
+ <configuration>
+ <inputSpec>${basedir}/src/main/resources/SOL003-VNFPackageManagement-Notification-API.json</inputSpec>
+ <language>java</language>
+ <library>okhttp-gson</library>
+ <output>${project.build.directory}/generated-sources/sol003-vnf-packagemanagement/notification</output>
+ <apiPackage>org.onap.so.adapters.vnfmadapter.extclients.vnfm.packagemanagement.notification.api</apiPackage>
+ <modelPackage>org.onap.so.adapters.vnfmadapter.extclients.vnfm.packagemanagement.notification.model</modelPackage>
+ <configOptions>
+ <sourceFolder>src/gen/java/main</sourceFolder>
+ <withXml>true</withXml>
+ <useRxJava2>true</useRxJava2>
+ <serializableModel>true</serializableModel>
+ <dateLibrary>java8-localdatetime</dateLibrary>
+ </configOptions>
+ </configuration>
+ </execution>
+ <execution>
+ <id>sol003-packagemanagement-api</id>
+ <goals>
+ <goal>generate</goal>
+ </goals>
+ <configuration>
+ <inputSpec>${basedir}/src/main/resources/SOL003-VNFPackageManagement-API.json</inputSpec>
+ <language>java</language>
+ <library>okhttp-gson</library>
+ <output>${project.build.directory}/generated-sources/sol003-vnf-packagemanagement</output>
+ <apiPackage>org.onap.so.adapters.vnfmadapter.extclients.vnfm.packagemanagement.api</apiPackage>
+ <modelPackage>org.onap.so.adapters.vnfmadapter.extclients.vnfm.packagemanagement.model</modelPackage>
+ <configOptions>
+ <sourceFolder>src/gen/java/main</sourceFolder>
+ <withXml>true</withXml>
+ <useRxJava2>true</useRxJava2>
+ <serializableModel>true</serializableModel>
+ </configOptions>
+ </configuration>
+ </execution>
</executions>
</plugin>
</plugins>
@@ -117,5 +158,23 @@
<groupId>javax.activation</groupId>
<artifactId>activation</artifactId>
</dependency>
+ <dependency>
+ <groupId>com.squareup.okhttp</groupId>
+ <artifactId>okhttp</artifactId>
+ <version>2.7.5</version>
+ <scope>compile</scope>
+ </dependency>
+ <dependency>
+ <groupId>com.squareup.okhttp</groupId>
+ <artifactId>logging-interceptor</artifactId>
+ <version>2.7.5</version>
+ <scope>compile</scope>
+ </dependency>
+ <dependency>
+ <groupId>junit</groupId>
+ <artifactId>junit</artifactId>
+ <version>4.12</version>
+ <scope>compile</scope>
+ </dependency>
</dependencies>
-</project>
\ No newline at end of file
+</project>
diff --git a/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-api/src/main/resources/SOL003-VNFPackageManagement-API.json b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-api/src/main/resources/SOL003-VNFPackageManagement-API.json
new file mode 100644
index 0000000..17d81f4
--- /dev/null
+++ b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-api/src/main/resources/SOL003-VNFPackageManagement-API.json
@@ -0,0 +1,7352 @@
+{
+ "swagger": "2.0",
+ "info": {
+ "version": "1.2.0-impl:etsi.org:ETSI_NFV_OpenAPI:1",
+ "title": "SOL003 - VNF Package Management interface",
+ "description": "SOL003 - VNF Package Management interface\n\nIMPORTANT: 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.\n\nIn 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.\nPlease report bugs to https://forge.etsi.org/bugzilla/buglist.cgi?component=Nfv-Openapis&list_id=61&product=NFV&resolution=\n",
+ "license": {
+ "name": "ETSI Forge copyright notice",
+ "url": "https://forge.etsi.org/etsi-forge-copyright-notice.txt"
+ }
+ },
+ "externalDocs": {
+ "description": "ETSI GS NFV-SOL 003 V2.5.1",
+ "url": "https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/02.05.01_60/gs_nfv-sol003v020501p.pdf"
+ },
+ "basePath": "/vnfpkgm/v1",
+ "schemes": [
+ "https"
+ ],
+ "consumes": [
+ "application/json"
+ ],
+ "produces": [
+ "application/json"
+ ],
+ "paths": {
+ "/api-versions": {
+ "parameters": [
+ {
+ "name": "Version",
+ "description": "Version of the API requested to use when responding to this request.\n",
+ "in": "header",
+ "required": false,
+ "type": "string"
+ }
+ ],
+ "get": {
+ "summary": "Retrieve API version information",
+ "description": "The GET method reads API version information. This method shall follow the provisions specified in table 4.6.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n",
+ "responses": {
+ "200": {
+ "description": "200 OK\nAPI version information was read successfully. The response body shall contain 4.4 API version information, as defined in clause 4.4.1.13.\n",
+ "schema": {
+ "description": "This type represents API version information. It shall comply with the provisions defined in table 4.4.1.13-1 (SOL003).\n",
+ "type": "object",
+ "required": [
+ "uriPrefix",
+ "apiVersions"
+ ],
+ "properties": {
+ "uriPrefix": {
+ "description": "Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/\n",
+ "type": "string"
+ },
+ "apiVersions": {
+ "description": "Version(s) supported for the API signaled by the uriPrefix attribute.\n",
+ "type": "array",
+ "items": {
+ "type": "object",
+ "required": [
+ "version"
+ ],
+ "properties": {
+ "version": {
+ "description": "Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 4.6.1.\n",
+ "type": "string"
+ },
+ "isDeprecated": {
+ "description": "If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false). A deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n",
+ "type": "boolean"
+ },
+ "retirementDate": {
+ "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n",
+ "type": "string",
+ "format": "date-time"
+ }
+ }
+ }
+ }
+ }
+ },
+ "headers": {
+ "Content-Type": {
+ "description": "The MIME type of the body of the response.",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ },
+ "Version": {
+ "description": "The used API version.",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ }
+ },
+ "400": {
+ "description": "400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), 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.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it 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.\nIf 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.\nIf 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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "401": {
+ "description": "401 UNAUTHORIZED\nIf 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "403": {
+ "description": "403 FORBIDDEN\nIf 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "404": {
+ "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "405": {
+ "description": "405 METHOD NOT ALLOWED\nIf 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "406": {
+ "description": "406 NOT ACCEPTABLE\nIf the \"Accept\" 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "413": {
+ "description": "413 PAYLOAD TOO LARGE\nIf the payload body of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "414": {
+ "description": "414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "416": {
+ "description": "416 RANGE NOT SATISFIABLE\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "422": {
+ "description": "422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), 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.\nThis error response code is only applicable for methods that have a request body.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "429": {
+ "description": "429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "500": {
+ "description": "500 INTERNAL SERVER ERROR\nIf 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 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "503": {
+ "description": "503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "504": {
+ "description": "504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ }
+ }
+ }
+ },
+ "/vnf_packages": {
+ "get": {
+ "description": "Query VNF Package Info\n\nThe GET method queries the information of the VNF packages matching the filter.\n",
+ "parameters": [
+ {
+ "name": "Accept",
+ "description": "Content-Types that are acceptable for the response. Reference: IETF RFC 7231\n",
+ "in": "header",
+ "required": true,
+ "type": "string"
+ },
+ {
+ "name": "Authorization",
+ "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
+ "in": "header",
+ "required": false,
+ "type": "string"
+ },
+ {
+ "name": "filter",
+ "description": "Attribute-based filtering expression according to clause 4.3.2. The VNFM shall support receiving this parameter as part of the URI query string. The NFVO may supply this parameter. All attribute names that appear in the VnfPkgInfo and in data types referenced from it shall be supported by the VNFM in the filter expression.\n",
+ "in": "query",
+ "required": false,
+ "type": "string"
+ },
+ {
+ "name": "all_fields",
+ "description": "Include all complex attributes in the response. See clause 4.3.3 for details. The VNFM shall support this parameter.\n",
+ "in": "query",
+ "required": false,
+ "type": "string"
+ },
+ {
+ "name": "fields",
+ "description": "Complex attributes to be included into the response. See clause 4.3.3 for details. The VNFM should support this parameter.\n",
+ "in": "query",
+ "required": false,
+ "type": "string"
+ },
+ {
+ "name": "exclude_fields",
+ "description": "Complex attributes to be excluded from the response. See clause 4.3.3 for details. The VNFM should support this parameter.\n",
+ "in": "query",
+ "required": false,
+ "type": "string"
+ },
+ {
+ "name": "exclude_default",
+ "description": "Indicates to exclude the following complex attributes from the response. See clause 4.3.3 for details. The VNFM shall support this parameter. The following attributes shall be excluded from the VnfPkgInfo structure in the response body if this parameter is provided, or none of the parameters \"all_fields,\" \"fields\", \"exclude_fields\", \"exclude_default\" are provided: -\tsoftwareImages -\tadditionalArtifacts -\tuserDefinedData.\n",
+ "in": "query",
+ "required": false,
+ "type": "string"
+ },
+ {
+ "name": "nextpage_opaque_marker",
+ "description": "Marker to obtain the next page of a paged response. Shall be supported by the VNFM if the VNFM supports alternative 2 (paging) according to clause 4.7.2.1 for this resource.\n",
+ "in": "query",
+ "required": false,
+ "type": "string"
+ },
+ {
+ "name": "Version",
+ "description": "Version of the API requested to use when responding to this request.\n",
+ "in": "header",
+ "required": true,
+ "type": "string"
+ }
+ ],
+ "responses": {
+ "200": {
+ "description": "200 OK\nInformation about zero or more VNF packages was queried successfully. The response body shall contain in an array the VNF package info representations that match the attribute filter, i.e. zero or more VNF package representations as defined in clause 10.5.2.2. If the VNFM supports alternative 2 (paging) according to clause 4.7.2.1 for this resource, inclusion of the Link HTTP header in this response shall follow the provisions in clause 4.7.2.3.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ },
+ "Link": {
+ "description": "Reference to other resources. Used for paging in the present document, see clause 4.7.2.1.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ }
+ },
+ "schema": {
+ "type": "array",
+ "items": {
+ "description": "This type represents the information of an VNF package.\n",
+ "type": "object",
+ "required": [
+ "id",
+ "operationalState",
+ "usageState",
+ "_links"
+ ],
+ "properties": {
+ "id": {
+ "description": "An identifier with the intention of being globally unique.\n",
+ "type": "string"
+ },
+ "vnfdId": {
+ "description": "An identifier with the intention of being globally unique.\n",
+ "type": "string"
+ },
+ "vnfProvider": {
+ "description": "Provider of the VNF package and the VNFD. This information is copied from the VNFD.\n",
+ "type": "string"
+ },
+ "vnfProductName": {
+ "description": "Name to identify the VNF product. Invariant for the VNF product lifetime. This information is copied from the VNFD. It shall be present after the VNF package content has been on-boarded and absent otherwise.\n",
+ "type": "string"
+ },
+ "vnfSoftwareVersion": {
+ "description": "A Version.\n",
+ "type": "string"
+ },
+ "vnfdVersion": {
+ "description": "A Version.\n",
+ "type": "string"
+ },
+ "checksum": {
+ "description": "This type represents the checksum of a VNF package or an artifact file.\n",
+ "type": "object",
+ "required": [
+ "algorithm",
+ "hash"
+ ],
+ "properties": {
+ "algorithm": {
+ "description": "Name of the algorithm used to generate the checksum, as defined in ETSI GS NFV-SOL 004. For example, SHA-256, SHA-512.\n",
+ "type": "string"
+ },
+ "hash": {
+ "description": "The hexadecimal value of the checksum.\n",
+ "type": "string"
+ }
+ }
+ },
+ "softwareImages": {
+ "description": "Information about VNF package artifacts that are software images. This attribute shall not be present before the VNF package content is on-boarded. Otherwise, this attribute shall be present unless it has been requested to be excluded per attribute selector.\n",
+ "type": "array",
+ "items": {
+ "description": "This type represents an artifact contained in a VNF package which represents a software image.\n",
+ "type": "object",
+ "required": [
+ "id",
+ "name",
+ "provider",
+ "version",
+ "checksum",
+ "containerFormat",
+ "diskFormat",
+ "createdAt",
+ "minDisk",
+ "minRam",
+ "size",
+ "imagePath"
+ ],
+ "properties": {
+ "id": {
+ "description": "An identifier that is unique within a VNF descriptor.\n",
+ "type": "string"
+ },
+ "name": {
+ "description": "Name of the software image.\n",
+ "type": "string"
+ },
+ "provider": {
+ "description": "Provider of the software image.\n",
+ "type": "string"
+ },
+ "version": {
+ "description": "A Version.\n",
+ "type": "string"
+ },
+ "checksum": {
+ "description": "This type represents the checksum of a VNF package or an artifact file.\n",
+ "type": "object",
+ "required": [
+ "algorithm",
+ "hash"
+ ],
+ "properties": {
+ "algorithm": {
+ "description": "Name of the algorithm used to generate the checksum, as defined in ETSI GS NFV-SOL 004. For example, SHA-256, SHA-512.\n",
+ "type": "string"
+ },
+ "hash": {
+ "description": "The hexadecimal value of the checksum.\n",
+ "type": "string"
+ }
+ }
+ },
+ "containerFormat": {
+ "description": "Container format indicates whether the software image is in a file format that also contains metadata about the actual software. Permitted values: - AKI: a kernel image format - AMI: a machine image format - ARI: a ramdisk image format - BARE: the image does not have a container or metadata envelope - DOCKER: docker container format - OVA: OVF package in a tarfile - OVF: OVF container format The list of permitted values was taken from \"Container formats\" in http://docs.openstack.org/image-guide/image-formats.html\n",
+ "type": "string",
+ "enum": [
+ "AKI",
+ "AMI",
+ "ARI",
+ "BARE",
+ "DOCKER",
+ "OVA",
+ "OVF"
+ ]
+ },
+ "diskFormat": {
+ "description": "Disk format of a software image is the format of the underlying disk image. Permitted values: - AKI: a kernel image format - AMI: a machine image format - ARI: a ramdisk image format - ISO: an archive format for the data contents of an optical disc, such as CD-ROM\n- QCOW2: a common disk image format, which can expand dynamically and supports copy on write\n- RAW: an unstructured disk image format - VDI: a common disk image format - VHD: a common disk image format - VHDX: enhanced version of VHD format - VMDK: a common disk image format The list of permitted values was adapted from \"Disk formats\" in http://docs.openstack.org/image-guide/image-formats.html\n",
+ "type": "string",
+ "enum": [
+ "AKI",
+ "AMI",
+ "ISO",
+ "QCOW2",
+ "RAW",
+ "VDI",
+ "VHD",
+ "VHDX",
+ "VMDK"
+ ]
+ },
+ "createdAt": {
+ "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "minDisk": {
+ "description": "The minimal disk for this software image in bytes.\n",
+ "type": "integer"
+ },
+ "minRam": {
+ "description": "The minimal RAM for this software image in bytes.\n",
+ "type": "integer"
+ },
+ "size": {
+ "description": "Size of this software image in bytes.\n",
+ "type": "integer"
+ },
+ "userMetadata": {
+ "description": "This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.\n",
+ "type": "object"
+ },
+ "imagePath": {
+ "description": "Path in the VNF package, which identifies the image artifact and also allows to access a copy of the image artifact.\n",
+ "type": "string"
+ }
+ }
+ }
+ },
+ "additionalArtifacts": {
+ "description": "Information about VNF package artifacts contained in the VNF package that are not software images. This attribute shall not be present before the VNF package content is on-boarded. Otherwise, this attribute shall be present if the VNF package contains additional artifacts.\n",
+ "type": "array",
+ "items": {
+ "description": "This type represents an artifact other than a software image which is contained in a VNF package.\n",
+ "type": "object",
+ "required": [
+ "artifactPath",
+ "checksum"
+ ],
+ "properties": {
+ "artifactPath": {
+ "description": "Path in the VNF package, which identifies the artifact and also allows to access a copy of the artifact.\n",
+ "type": "string"
+ },
+ "checksum": {
+ "description": "This type represents the checksum of a VNF package or an artifact file.\n",
+ "type": "object",
+ "required": [
+ "algorithm",
+ "hash"
+ ],
+ "properties": {
+ "algorithm": {
+ "description": "Name of the algorithm used to generate the checksum, as defined in ETSI GS NFV-SOL 004. For example, SHA-256, SHA-512.\n",
+ "type": "string"
+ },
+ "hash": {
+ "description": "The hexadecimal value of the checksum.\n",
+ "type": "string"
+ }
+ }
+ },
+ "metadata": {
+ "description": "This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.\n",
+ "type": "object"
+ }
+ }
+ }
+ },
+ "onboardingState": {
+ "description": "CREATED: The VNF package resource has been created. UPLOADING: The associated VNF package content is being uploaded. PROCESSING: The associated VNF package content is being processed, e.g., validation.\nONBOARDED: The associated VNF package content has been successfully on-boarded.\n",
+ "type": "string",
+ "enum": [
+ "CREATED",
+ "UPLOADING",
+ "PROCESSING",
+ "ONBOARDED"
+ ]
+ },
+ "operationalState": {
+ "description": "- ENABLED: The VNF package is enabled, i.e. it can be used for instantiation of new VNF instances.\n- DISABLED: The VNF package is disabled, i.e. it cannot be used for further VNF instantiation requests (unless and until the VNF package\n is re-enabled).\n",
+ "type": "string",
+ "enum": [
+ "ENABLED",
+ "DISABLED"
+ ]
+ },
+ "usageState":
+ {
+ "description": "- IN_USE: VNF instances instantiated from this VNF package exist. - NOT_IN_USE: No existing VNF instance is instantiated from this VNF package.\n",
+ "type": "string",
+ "enum": [
+ "IN_USE",
+ "NOT_IN_USE"
+ ]
+ },
+ "userDefinedData": {
+ "description": "This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.\n",
+ "type": "object"
+ },
+ "_links": {
+ "description": "Links to resources related to this resource.\n",
+ "type": "object",
+ "required": [
+ "self",
+ "packageContent"
+ ],
+ "properties": {
+ "self": {
+ "description": "This type represents a link to a resource using an absolute URI. It shall comply with the provisions defined in table 4.4.1.3-1.\n",
+ "type": "object",
+ "required": [
+ "href"
+ ],
+ "properties": {
+ "href": {
+ "description": "String formatted according to IETF RFC 3986.\n",
+ "type": "string"
+ }
+ }
+ },
+ "vnfd": {
+ "description": "This type represents a link to a resource using an absolute URI. It shall comply with the provisions defined in table 4.4.1.3-1.\n",
+ "type": "object",
+ "required": [
+ "href"
+ ],
+ "properties": {
+ "href": {
+ "description": "String formatted according to IETF RFC 3986.\n",
+ "type": "string"
+ }
+ }
+ },
+ "packageContent": {
+ "description": "This type represents a link to a resource using an absolute URI. It shall comply with the provisions defined in table 4.4.1.3-1.\n",
+ "type": "object",
+ "required": [
+ "href"
+ ],
+ "properties": {
+ "href": {
+ "description": "String formatted according to IETF RFC 3986.\n",
+ "type": "string"
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ },
+ "400": {
+ "description": "400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), 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.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it 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.\nIf 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.\nIf 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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "401": {
+ "description": "401 UNAUTHORIZED\nIf 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "403": {
+ "description": "403 FORBIDDEN\nIf 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "404": {
+ "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "405": {
+ "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "406": {
+ "description": "406 NOT ACCEPTABLE\nIf the \"Accept\" 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "416": {
+ "description": "416 RANGE NOT SATISFIABLE\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "500": {
+ "description": "500 INTERNAL SERVER ERROR\nIf 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 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "503": {
+ "description": "503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ }
+ }
+ }
+ },
+ "/vnf_packages/{vnfPkgId}": {
+ "parameters": [
+ {
+ "name": "vnfPkgId",
+ "description": "Identifier of the VNF package. The identifier is allocated by the NFVO. This identifier can be retrieved from the \"vnfPkgId\" attribute in the VnfPackageOnboardingNotification or VnfPackageChangeNotification.\n",
+ "in": "path",
+ "type": "string",
+ "required": true
+ }
+ ],
+ "get": {
+ "description": "Query VNF Package Info\n\nThe GET method reads the information of an individual VNF package.\n",
+ "parameters": [
+ {
+ "name": "Accept",
+ "description": "Content-Types that are acceptable for the response. Reference: IETF RFC 7231\n",
+ "in": "header",
+ "required": true,
+ "type": "string"
+ },
+ {
+ "name": "Authorization",
+ "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
+ "in": "header",
+ "required": false,
+ "type": "string"
+ },
+ {
+ "name": "Version",
+ "description": "Version of the API requested to use when responding to this request.\n",
+ "in": "header",
+ "required": true,
+ "type": "string"
+ }
+ ],
+ "responses": {
+ "200": {
+ "description": "200 OK\nInformation of the selected VNF packages.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ },
+ "schema": {
+ "description": "This type represents the information of an VNF package.\n",
+ "type": "object",
+ "required": [
+ "id",
+ "operationalState",
+ "usageState",
+ "_links"
+ ],
+ "properties": {
+ "id": {
+ "description": "An identifier with the intention of being globally unique.\n",
+ "type": "string"
+ },
+ "vnfdId": {
+ "description": "An identifier with the intention of being globally unique.\n",
+ "type": "string"
+ },
+ "vnfProvider": {
+ "description": "Provider of the VNF package and the VNFD. This information is copied from the VNFD.\n",
+ "type": "string"
+ },
+ "vnfProductName": {
+ "description": "Name to identify the VNF product. Invariant for the VNF product lifetime. This information is copied from the VNFD. It shall be present after the VNF package content has been on-boarded and absent otherwise.\n",
+ "type": "string"
+ },
+ "vnfSoftwareVersion": {
+ "description": "A Version.\n",
+ "type": "string"
+ },
+ "vnfdVersion": {
+ "description": "A Version.\n",
+ "type": "string"
+ },
+ "checksum": {
+ "description": "This type represents the checksum of a VNF package or an artifact file.\n",
+ "type": "object",
+ "required": [
+ "algorithm",
+ "hash"
+ ],
+ "properties": {
+ "algorithm": {
+ "description": "Name of the algorithm used to generate the checksum, as defined in ETSI GS NFV-SOL 004. For example, SHA-256, SHA-512.\n",
+ "type": "string"
+ },
+ "hash": {
+ "description": "The hexadecimal value of the checksum.\n",
+ "type": "string"
+ }
+ }
+ },
+ "softwareImages": {
+ "description": "Information about VNF package artifacts that are software images. This attribute shall not be present before the VNF package content is on-boarded. Otherwise, this attribute shall be present unless it has been requested to be excluded per attribute selector.\n",
+ "type": "array",
+ "items": {
+ "description": "This type represents an artifact contained in a VNF package which represents a software image.\n",
+ "type": "object",
+ "required": [
+ "id",
+ "name",
+ "provider",
+ "version",
+ "checksum",
+ "containerFormat",
+ "diskFormat",
+ "createdAt",
+ "minDisk",
+ "minRam",
+ "size",
+ "imagePath"
+ ],
+ "properties": {
+ "id": {
+ "description": "An identifier that is unique within a VNF descriptor.\n",
+ "type": "string"
+ },
+ "name": {
+ "description": "Name of the software image.\n",
+ "type": "string"
+ },
+ "provider": {
+ "description": "Provider of the software image.\n",
+ "type": "string"
+ },
+ "version": {
+ "description": "A Version.\n",
+ "type": "string"
+ },
+ "checksum": {
+ "description": "This type represents the checksum of a VNF package or an artifact file.\n",
+ "type": "object",
+ "required": [
+ "algorithm",
+ "hash"
+ ],
+ "properties": {
+ "algorithm": {
+ "description": "Name of the algorithm used to generate the checksum, as defined in ETSI GS NFV-SOL 004. For example, SHA-256, SHA-512.\n",
+ "type": "string"
+ },
+ "hash": {
+ "description": "The hexadecimal value of the checksum.\n",
+ "type": "string"
+ }
+ }
+ },
+ "containerFormat": {
+ "description": "Container format indicates whether the software image is in a file format that also contains metadata about the actual software. Permitted values: - AKI: a kernel image format - AMI: a machine image format - ARI: a ramdisk image format - BARE: the image does not have a container or metadata envelope - DOCKER: docker container format - OVA: OVF package in a tarfile - OVF: OVF container format The list of permitted values was taken from \"Container formats\" in http://docs.openstack.org/image-guide/image-formats.html\n",
+ "type": "string",
+ "enum": [
+ "AKI",
+ "AMI",
+ "ARI",
+ "BARE",
+ "DOCKER",
+ "OVA",
+ "OVF"
+ ]
+ },
+ "diskFormat": {
+ "description": "Disk format of a software image is the format of the underlying disk image. Permitted values: - AKI: a kernel image format - AMI: a machine image format - ARI: a ramdisk image format - ISO: an archive format for the data contents of an optical disc, such as CD-ROM\n- QCOW2: a common disk image format, which can expand dynamically and supports copy on write\n- RAW: an unstructured disk image format - VDI: a common disk image format - VHD: a common disk image format - VHDX: enhanced version of VHD format - VMDK: a common disk image format The list of permitted values was adapted from \"Disk formats\" in http://docs.openstack.org/image-guide/image-formats.html\n",
+ "type": "string",
+ "enum": [
+ "AKI",
+ "AMI",
+ "ISO",
+ "QCOW2",
+ "RAW",
+ "VDI",
+ "VHD",
+ "VHDX",
+ "VMDK"
+ ]
+ },
+ "createdAt": {
+ "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "minDisk": {
+ "description": "The minimal disk for this software image in bytes.\n",
+ "type": "integer"
+ },
+ "minRam": {
+ "description": "The minimal RAM for this software image in bytes.\n",
+ "type": "integer"
+ },
+ "size": {
+ "description": "Size of this software image in bytes.\n",
+ "type": "integer"
+ },
+ "userMetadata": {
+ "description": "This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.\n",
+ "type": "object"
+ },
+ "imagePath": {
+ "description": "Path in the VNF package, which identifies the image artifact and also allows to access a copy of the image artifact.\n",
+ "type": "string"
+ }
+ }
+ }
+ },
+ "additionalArtifacts": {
+ "description": "Information about VNF package artifacts contained in the VNF package that are not software images. This attribute shall not be present before the VNF package content is on-boarded. Otherwise, this attribute shall be present if the VNF package contains additional artifacts.\n",
+ "type": "array",
+ "items": {
+ "description": "This type represents an artifact other than a software image which is contained in a VNF package.\n",
+ "type": "object",
+ "required": [
+ "artifactPath",
+ "checksum"
+ ],
+ "properties": {
+ "artifactPath": {
+ "description": "Path in the VNF package, which identifies the artifact and also allows to access a copy of the artifact.\n",
+ "type": "string"
+ },
+ "checksum": {
+ "description": "This type represents the checksum of a VNF package or an artifact file.\n",
+ "type": "object",
+ "required": [
+ "algorithm",
+ "hash"
+ ],
+ "properties": {
+ "algorithm": {
+ "description": "Name of the algorithm used to generate the checksum, as defined in ETSI GS NFV-SOL 004. For example, SHA-256, SHA-512.\n",
+ "type": "string"
+ },
+ "hash": {
+ "description": "The hexadecimal value of the checksum.\n",
+ "type": "string"
+ }
+ }
+ },
+ "metadata": {
+ "description": "This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.\n",
+ "type": "object"
+ }
+ }
+ }
+ },
+ "onboardingState": {
+ "description": "CREATED: The VNF package resource has been created. UPLOADING: The associated VNF package content is being uploaded. PROCESSING: The associated VNF package content is being processed, e.g., validation.\nONBOARDED: The associated VNF package content has been successfully on-boarded.\n",
+ "type": "string",
+ "enum": [
+ "CREATED",
+ "UPLOADING",
+ "PROCESSING",
+ "ONBOARDED"
+ ]
+ },
+ "operationalState": {
+ "description": "- ENABLED: The VNF package is enabled, i.e. it can be used for instantiation of new VNF instances.\n- DISABLED: The VNF package is disabled, i.e. it cannot be used for further VNF instantiation requests (unless and until the VNF package\n is re-enabled).\n",
+ "type": "string",
+ "enum": [
+ "ENABLED",
+ "DISABLED"
+ ]
+ },
+ "usageState":
+ {
+ "description": "- IN_USE: VNF instances instantiated from this VNF package exist. - NOT_IN_USE: No existing VNF instance is instantiated from this VNF package.\n",
+ "type": "string",
+ "enum": [
+ "IN_USE",
+ "NOT_IN_USE"
+ ]
+ },
+ "userDefinedData": {
+ "description": "This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.\n",
+ "type": "object"
+ },
+ "_links": {
+ "description": "Links to resources related to this resource.\n",
+ "type": "object",
+ "required": [
+ "self",
+ "packageContent"
+ ],
+ "properties": {
+ "self": {
+ "description": "This type represents a link to a resource using an absolute URI. It shall comply with the provisions defined in table 4.4.1.3-1.\n",
+ "type": "object",
+ "required": [
+ "href"
+ ],
+ "properties": {
+ "href": {
+ "description": "String formatted according to IETF RFC 3986.\n",
+ "type": "string"
+ }
+ }
+ },
+ "vnfd": {
+ "description": "This type represents a link to a resource using an absolute URI. It shall comply with the provisions defined in table 4.4.1.3-1.\n",
+ "type": "object",
+ "required": [
+ "href"
+ ],
+ "properties": {
+ "href": {
+ "description": "String formatted according to IETF RFC 3986.\n",
+ "type": "string"
+ }
+ }
+ },
+ "packageContent": {
+ "description": "This type represents a link to a resource using an absolute URI. It shall comply with the provisions defined in table 4.4.1.3-1.\n",
+ "type": "object",
+ "required": [
+ "href"
+ ],
+ "properties": {
+ "href": {
+ "description": "String formatted according to IETF RFC 3986.\n",
+ "type": "string"
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ },
+ "400": {
+ "description": "400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), 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.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it 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.\nIf 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.\nIf 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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "401": {
+ "description": "401 UNAUTHORIZED\nIf 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "403": {
+ "description": "403 FORBIDDEN\nIf 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "404": {
+ "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "405": {
+ "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "406": {
+ "description": "406 NOT ACCEPTABLE\nIf the \"Accept\" 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "416": {
+ "description": "416 RANGE NOT SATISFIABLE\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "500": {
+ "description": "500 INTERNAL SERVER ERROR\nIf 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 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "503": {
+ "description": "503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ }
+ }
+ }
+ },
+ "/vnf_packages/{vnfPkgId}/vnfd": {
+ "parameters": [
+ {
+ "name": "vnfPkgId",
+ "description": "Identifier of the on-boarded VNF package. The identifier is allocated by the NFVO. This identifier can be retrieved from the \"vnfPkgId\" attribute in the VnfPackageOnboardingNotification or VnfPackageChangeNotification.\n",
+ "in": "path",
+ "type": "string",
+ "required": true
+ }
+ ],
+ "get": {
+ "description": "Query VNF Package Info\n\nThe GET method reads the content of the VNFD within a VNF package. The VNFD can be implemented as a single file or as a collection of multiple files. If the VNFD is implemented in the form of multiple files, a ZIP file embedding these files shall be returned. If the VNFD is implemented as a single file, either that file or a ZIP file embedding that file shall be returned. The selection of the format is controlled by the \"Accept\" HTTP header passed in the GET request. * If the \"Accept\" header contains only \"text/plain\" and the VNFD is implemented as a single file, the file shall be returned;\n otherwise, an error message shall be returned.\n* If the \"Accept\" header contains only \"application/zip\", the single file or the multiple files that make up the VNFD shall be returned\n embedded in a ZIP file.\n* If the \"Accept\" header contains both \"text/plain\" and \"application/zip\", it is up to the NFVO to choose the format to\n return for a single-file VNFD; for a multi-file VNFD, a ZIP file\n shall be returned.\nThe default format of the ZIP file shall be the one specified in ETSI GS NFV-SOL 004 where only the YAML files representing the VNFD, and information needed to navigate the ZIP file and to identify the file that is the entry point for parsing the VNFD (such as TOSCA-meta or manifest files or naming conventions) are included.\n",
+ "parameters": [
+ {
+ "name": "Accept",
+ "description": "Content-Types that are acceptable for the response. Permitted values: \"text/plain\" and/or \"application/zip\" Reference: IETF RFC 7231\n",
+ "in": "header",
+ "required": true,
+ "type": "string",
+ "enum": [
+ "text/plain",
+ "application/zip",
+ "text/plain+application/zip"
+ ]
+ },
+ {
+ "name": "Authorization",
+ "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
+ "in": "header",
+ "required": false,
+ "type": "string"
+ },
+ {
+ "name": "Version",
+ "description": "Version of the API requested to use when responding to this request.\n",
+ "in": "header",
+ "required": true,
+ "type": "string"
+ }
+ ],
+ "responses": {
+ "200": {
+ "description": "200 OK\nOn success, the content of the VNFD is returned. The payload body shall contain a copy of the file representing the VNFD or a ZIP file that contains the file or multiple files representing the VNFD, as specified above. The \"Content-Type\" HTTP header shall be set according to the format of the returned file, i.e. to \"text/plain\" for a YAML file or to \"application/zip\" for a ZIP file.\n",
+ "headers": {
+ "Content-Type": {
+ "description": "The MIME type of the body of the response.",
+ "type": "string",
+ "enum": [
+ "text/plain",
+ "application/zip"
+ ],
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ }
+ },
+ "400": {
+ "description": "400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), 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.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it 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.\nIf 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.\nIf 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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "401": {
+ "description": "401 UNAUTHORIZED\nIf 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "403": {
+ "description": "403 FORBIDDEN\nIf 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "404": {
+ "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "405": {
+ "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "406": {
+ "description": "Not Acceptable\nIf the \"Accept\" header does not contain at least one name of a content type for which the NFVO can provide a representation of the VNFD, the NFVO shall respond with this response code. The \"ProblemDetails\" structure may be included with the \"detail\" attribute providing more information about the error.\n",
+ "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.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "409": {
+ "description": "Conflict\nError: The operation cannot be executed currently, due to a conflict with the state of the resource. Typically, this is due to the fact that \"onboardingState\" of the VNF package has a value different from \"ONBOARDED\". The response body shall contain a ProblemDetails structure, in which the \"detail\" attribute shall convey more information about the error.\n",
+ "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.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "416": {
+ "description": "416 RANGE NOT SATISFIABLE\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "500": {
+ "description": "500 INTERNAL SERVER ERROR\nIf 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 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "503": {
+ "description": "503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ }
+ }
+ }
+ },
+ "/vnf_packages/{vnfPkgId}/package_content": {
+ "parameters": [
+ {
+ "name": "vnfPkgId",
+ "description": "Identifier of the VNF package. The identifier is allocated by the NFVO. This identifier can be retrieved from the \"vnfPkgId\" attribute in the VnfPackageOnboardingNotification or VnfPackageChangeNotification.\n",
+ "in": "path",
+ "type": "string",
+ "required": true
+ }
+ ],
+ "get": {
+ "description": "Fetch VNF Package\n\nThe GET method fetches the content of a VNF package identified by the VNF package identifier allocated by the NFVO.\n",
+ "parameters": [
+ {
+ "name": "Accept",
+ "description": "Content-Types that are acceptable for the response.\n",
+ "in": "header",
+ "required": true,
+ "type": "string",
+ "enum": [
+ "text/plain",
+ "application/zip"
+ ]
+ },
+ {
+ "name": "Authorization",
+ "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
+ "in": "header",
+ "required": false,
+ "type": "string"
+ },
+ {
+ "name": "Range",
+ "description": "The request may contain a \"Range\" HTTP header to obtain single range of bytes from the VNF package file. This can be used to continue an aborted transmission. If the NFVO does not support range requests, it should return the whole file with a 200 OK response instead.\n",
+ "in": "header",
+ "type": "string"
+ },
+ {
+ "name": "Version",
+ "description": "Version of the API requested to use when responding to this request.\n",
+ "in": "header",
+ "required": true,
+ "type": "string"
+ }
+ ],
+ "responses": {
+ "200": {
+ "description": "200 OK\nOn success, a copy of the VNF package file is returned. The response body shall include a copy of the VNF package file. The \"Content-Type HTTP\" header shall be set according to the type of the file, i.e. to \"application/zip\" for a VNF Package as defined in ETSI GS NFV-SOL 004.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ }
+ },
+ "206": {
+ "description": "206 PARTIAL CONTENT\nOn success, if the NFVO supports range requests, a single consecutive byte range from the content of the VNF package file is returned. The response body shall contain the requested part of the VNF package file. The \"Content-Range\" HTTP header shall be provided according to IETF RFC 7233. The \"Content-Type\" HTTP header shall be set as defined above for the \"200 OK\" response.\n",
+ "headers": {
+ "Content-Range": {
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ },
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ }
+ },
+ "400": {
+ "description": "400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), 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.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it 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.\nIf 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.\nIf 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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "401": {
+ "description": "401 UNAUTHORIZED\nIf 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "403": {
+ "description": "403 FORBIDDEN\nIf 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "404": {
+ "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "405": {
+ "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "406": {
+ "description": "406 NOT ACCEPTABLE\nIf the \"Accept\" 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "409": {
+ "description": "Conflict\nError: The operation cannot be executed currently, due to a conflict with the state of the resource. Typically, this is due to the fact that \"onboardingState\" of the VNF package has a value different from \"ONBOARDED\". The response body shall contain a ProblemDetails structure, in which the \"detail\" attribute shall convey more information about the error.\n",
+ "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.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "416": {
+ "description": "Requested Range Not Satisfiable\nThe byte range passed in the \"Range\" header did not match any available byte range in the VNF package file (e.g. \"access after end of file\"). The response body may contain a ProblemDetails structure.\n",
+ "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.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "500": {
+ "description": "500 INTERNAL SERVER ERROR\nIf 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 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "503": {
+ "description": "503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ }
+ }
+ }
+ },
+ "/vnf_packages/{vnfPkgId}/artifacts/{artifactPath}": {
+ "parameters": [
+ {
+ "name": "artifactPath",
+ "description": "Sequence of one or more path segments representing the path of the artifact within the VNF package. EXAMPLE: foo/bar/run.sh This identifier can be retrieved from the \"artifactPath\" attribute of the applicable \"additionalArtifacts\" entry in the body of the response to a GET request querying the \"Individual VNF package\" or the \"VNF packages\" resource.\n",
+ "in": "path",
+ "type": "string",
+ "required": true
+ },
+ {
+ "name": "vnfPkgId",
+ "description": "Identifier of the VNF package. The identifier is allocated by the NFVO. This identifier can be retrieved from the \"vnfPkgId\" attribute in the VnfPackageOnboardingNotification or VnfPackageChangeNotification.\n",
+ "in": "path",
+ "type": "string",
+ "required": true
+ }
+ ],
+ "get": {
+ "description": "Fetch VNF Package Artifacts\n\nThe GET method fetches the content of an artifact within a VNF package.\n",
+ "parameters": [
+ {
+ "name": "Accept",
+ "description": "Content-Types that are acceptable for the response.\n",
+ "in": "header",
+ "required": true,
+ "type": "string"
+ },
+ {
+ "name": "Authorization",
+ "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
+ "in": "header",
+ "required": false,
+ "type": "string"
+ },
+ {
+ "name": "Range",
+ "description": "The request may contain a \"Range\" HTTP header to obtain single range of bytes from the VNF package file. This can be used to continue an aborted transmission. If the NFVO does not support range requests, it should return the whole file with a 200 OK response instead.\n",
+ "in": "header",
+ "type": "string"
+ },
+ {
+ "name": "Version",
+ "description": "Version of the API requested to use when responding to this request.\n",
+ "in": "header",
+ "required": true,
+ "type": "string"
+ }
+ ],
+ "responses": {
+ "200": {
+ "description": "200 OK\nOn success, the content of the artifact is returned. The payload body shall contain a copy of the artifact file from the VNF package, as defined by ETSI GS NFV-SOL 004. The \"Content-Type\" HTTP header shall be set according to the content type of the artifact file. If the content type cannot be determined, the header shall be set to the value \"application/octet-stream\".\n",
+ "headers": {
+ "Content-Type": {
+ "description": "The MIME type of the body of the response. The \"Content-Type\" HTTP header shall be set according to the content type of the artifact file. If the content type cannot be determined, the header shall be set to the value \"application/octet-stream\".\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ }
+ },
+ "206": {
+ "description": "206 PARTIAL CONTENT\nOn success, if the NFVO supports range requests, a single consecutive byte range from the content of the VNF package file is returned. The response body shall contain the requested part of the VNF package file. The \"Content-Range\" HTTP header shall be provided according to IETF RFC 7233. The \"Content-Type\" HTTP header shall be set as defined above for the \"200 OK\" response.\n",
+ "headers": {
+ "Content-Range": {
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ },
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ }
+ },
+ "400": {
+ "description": "400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), 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.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it 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.\nIf 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.\nIf 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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "401": {
+ "description": "401 UNAUTHORIZED\nIf 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "403": {
+ "description": "403 FORBIDDEN\nIf 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "404": {
+ "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "405": {
+ "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "406": {
+ "description": "406 NOT ACCEPTABLE\nIf the \"Accept\" 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "409": {
+ "description": "Conflict\nError: The operation cannot be executed currently, due to a conflict with the state of the resource. Typically, this is due to the fact that \"onboardingState\" of the VNF package has a value different from \"ONBOARDED\". The response body shall contain a ProblemDetails structure, in which the \"detail\" attribute shall convey more information about the error.\n",
+ "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.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "416": {
+ "description": "Requested Range Not Satisfiable\nThe byte range passed in the \"Range\" header did not match any available byte range in the VNF package file (e.g. \"access after end of file\"). The response body may contain a ProblemDetails structure.\n",
+ "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.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "500": {
+ "description": "500 INTERNAL SERVER ERROR\nIf 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 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "503": {
+ "description": "503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ }
+ }
+ }
+ },
+ "/subscriptions": {
+ "post": {
+ "description": "Subscribe\n\nThe 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 VNFM, and might make sense only in very rare use cases. Consequently, the NFVO 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).\n",
+ "parameters": [
+ {
+ "name": "PkgmSubscriptionRequest",
+ "description": "Representation of the created subscription resource. The HTTP response shall include a \"Location\" HTTP header that points to the created subscription resource.\n",
+ "in": "body",
+ "required": true,
+ "schema": {
+ "description": "This type represents a subscription request related to VNF package management notifications about VNF package on-boarding or changes.\n",
+ "type": "object",
+ "required": [
+ "callbackUri"
+ ],
+ "properties": {
+ "filter": {
+ "description": "This type represents a subscription filter related to notifications related to VNF package management. 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": {
+ "notificationTypes": {
+ "description": "Match particular notification types. Permitted values: - VnfPackageOnboardingNotification - VnfPackageChangeNotification The permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the notification types to facilitate automated code generation systems.\n",
+ "type": "array",
+ "items": {
+ "type": "string",
+ "enum": [
+ "VnfPackageOnboardingNotification",
+ "VnfPackageChangeNotification"
+ ]
+ }
+ },
+ "vnfProductsFromProviders": {
+ "description": "If present, match VNF packages that contain VNF products from certain providers. The attributes \"vnfProductsFromProviders\", \"vnfdId\" and \"vnfPkgId\" are alternatives to reference to particular VNF packages 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 packages that contain 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 packages that contain 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 packages that contain 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"
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ },
+ "vnfdId": {
+ "description": "Match VNF packages with a VNFD identifier listed in the attribute. The attributes \"vnfProductsFromProviders\", \"vnfdId\" and \"vnfPkgId\" are alternatives to reference to particular VNF packages 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"
+ }
+ },
+ "vnfPkgId": {
+ "description": "Match VNF packages with a package identifier listed in the attribute. May be present if the \"notificationTypes\" attribute contains the value \"VnfPackageChangeNotification\", and shall be absent otherwise. The attributes \"vnfProductsFromProviders\", \"vnfdId\" and \"vnfPkgId\" are alternatives to reference to particular VNF packages 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"
+ }
+ },
+ "operationalState":
+ {
+ "description": "- ENABLED: The VNF package is enabled, i.e. it can be used for instantiation of new VNF instances.\n- DISABLED: The VNF package is disabled, i.e. it cannot be used for further VNF instantiation requests (unless and until the VNF package\n is re-enabled).\n",
+ "type": "array",
+ "items":
+ {
+ "type": "string",
+ "enum": [
+ "ENABLED",
+ "DISABLED"
+ ]
+ }
+ },
+ "usageState":
+ {
+ "description": "- IN_USE: VNF instances instantiated from this VNF package exist. - NOT_IN_USE: No existing VNF instance is instantiated from this VNF package.\n",
+ "type": "array",
+ "items":
+ {
+ "type": "string",
+ "enum": [
+ "IN_USE",
+ "NOT_IN_USE"
+ ]
+ }
+ }
+ }
+ },
+ "callbackUri": {
+ "description": "String formatted according to IETF RFC 3986.\n",
+ "type": "string"
+ },
+ "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. \n* OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the notification endpoint, use an OAuth 2.0 Bearer token, obtained\n using the client credentials grant type.\n* TLS_CERT: Every HTTP request to the notification endpoint is sent over a mutually authenticated TLS session, i.e. not only the\n server is authenticated, but also the client is authenticated\n during the TLS tunnel setup.\n",
+ "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.\n",
+ "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.\n",
+ "type": "string"
+ },
+ "password": {
+ "description": "Password to be used in HTTP Basic authentication. Shall be present if it has not been provisioned out of band.\n",
+ "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.\n",
+ "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.\n",
+ "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.\n",
+ "type": "string"
+ },
+ "tokenEndpoint": {
+ "description": "String formatted according to IETF RFC 3986.\n",
+ "type": "string"
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ },
+ {
+ "name": "Accept",
+ "description": "Content-Types that are acceptable for the response. Reference: IETF RFC 7231\n",
+ "in": "header",
+ "required": true,
+ "type": "string"
+ },
+ {
+ "name": "Authorization",
+ "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
+ "in": "header",
+ "required": false,
+ "type": "string"
+ },
+ {
+ "name": "Content-Type",
+ "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n",
+ "in": "header",
+ "required": true,
+ "type": "string"
+ },
+ {
+ "name": "Version",
+ "description": "Version of the API requested to use when responding to this request.\n",
+ "in": "header",
+ "required": true,
+ "type": "string"
+ }
+ ],
+ "responses": {
+ "201": {
+ "description": "201 CREATED\nRepresentation of the created subscription resource. The HTTP response shall include a \"Location\" HTTP header that points to the created subscription resource.\n",
+ "headers": {
+ "Content-Type": {
+ "description": "The MIME type of the body of the response.",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ },
+ "schema": {
+ "type": "array",
+ "items": {
+ "description": "This type represents a subscription related to notifications about VNF package management.\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 related to VNF package management. 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": {
+ "notificationTypes": {
+ "description": "Match particular notification types. Permitted values: - VnfPackageOnboardingNotification - VnfPackageChangeNotification The permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the notification types to facilitate automated code generation systems.\n",
+ "type": "array",
+ "items": {
+ "type": "string",
+ "enum": [
+ "VnfPackageOnboardingNotification",
+ "VnfPackageChangeNotification"
+ ]
+ }
+ },
+ "vnfProductsFromProviders": {
+ "description": "If present, match VNF packages that contain VNF products from certain providers. The attributes \"vnfProductsFromProviders\", \"vnfdId\" and \"vnfPkgId\" are alternatives to reference to particular VNF packages 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 packages that contain 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 packages that contain 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 packages that contain 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"
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ },
+ "vnfdId": {
+ "description": "Match VNF packages with a VNFD identifier listed in the attribute. The attributes \"vnfProductsFromProviders\", \"vnfdId\" and \"vnfPkgId\" are alternatives to reference to particular VNF packages 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"
+ }
+ },
+ "vnfPkgId": {
+ "description": "Match VNF packages with a package identifier listed in the attribute. May be present if the \"notificationTypes\" attribute contains the value \"VnfPackageChangeNotification\", and shall be absent otherwise. The attributes \"vnfProductsFromProviders\", \"vnfdId\" and \"vnfPkgId\" are alternatives to reference to particular VNF packages 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"
+ }
+ },
+ "operationalState":
+ {
+ "description": "- ENABLED: The VNF package is enabled, i.e. it can be used for instantiation of new VNF instances.\n- DISABLED: The VNF package is disabled, i.e. it cannot be used for further VNF instantiation requests (unless and until the VNF package\n is re-enabled).\n",
+ "type": "array",
+ "items":
+ {
+ "type": "string",
+ "enum": [
+ "ENABLED",
+ "DISABLED"
+ ]
+ }
+ },
+ "usageState":
+ {
+ "description": "- IN_USE: VNF instances instantiated from this VNF package exist. - NOT_IN_USE: No existing VNF instance is instantiated from this VNF package.\n",
+ "type": "array",
+ "items":
+ {
+ "type": "string",
+ "enum": [
+ "IN_USE",
+ "NOT_IN_USE"
+ ]
+ }
+ } }
+ },
+ "callbackUri": {
+ "description": "String formatted according to IETF RFC 3986.\n",
+ "type": "string"
+ },
+ "_links": {
+ "description": "Links to resources related to this resource.\n",
+ "type": "object",
+ "required": [
+ "self"
+ ],
+ "properties": {
+ "self": {
+ "description": "This type represents a link to a resource using an absolute URI. It shall comply with the provisions defined in table 4.4.1.3-1.\n",
+ "type": "object",
+ "required": [
+ "href"
+ ],
+ "properties": {
+ "href": {
+ "description": "String formatted according to IETF RFC 3986.\n",
+ "type": "string"
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ },
+ "303": {
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ }
+ },
+ "400": {
+ "description": "400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), 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.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it 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.\nIf 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.\nIf 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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "401": {
+ "description": "401 UNAUTHORIZED\nIf 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "403": {
+ "description": "403 FORBIDDEN\nIf 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "404": {
+ "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "405": {
+ "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "406": {
+ "description": "406 NOT ACCEPTABLE\nIf the \"Accept\" 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "416": {
+ "description": "416 RANGE NOT SATISFIABLE\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "500": {
+ "description": "500 INTERNAL SERVER ERROR\nIf 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 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "503": {
+ "description": "503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ }
+ }
+ },
+ "get": {
+ "description": "Query Subscription Information\n\nThe 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.\n",
+ "parameters": [
+ {
+ "name": "Accept",
+ "description": "Content-Types that are acceptable for the response. Reference: IETF RFC 7231\n",
+ "in": "header",
+ "required": true,
+ "type": "string"
+ },
+ {
+ "name": "Authorization",
+ "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
+ "in": "header",
+ "required": false,
+ "type": "string"
+ },
+ {
+ "name": "filter",
+ "description": "Attribute-based filtering expression according to clause 4.3.2. The VNFM shall support receiving this parameter as part of the URI query string. The NFVO may supply this parameter. All attribute names that appear in the PkgmSubscription and in data types referenced from it shall be supported by the VNFM in the filter expression.\n",
+ "in": "query",
+ "required": false,
+ "type": "string"
+ },
+ {
+ "name": "nextpage_opaque_marker",
+ "description": "Marker to obtain the next page of a paged response. Shall be supported by the VNFM if the VNFM supports alternative 2 (paging) according to clause 4.7.2.1 for this resource.\n",
+ "in": "query",
+ "required": false,
+ "type": "string"
+ },
+ {
+ "name": "Version",
+ "description": "Version of the API requested to use when responding to this request.\n",
+ "in": "header",
+ "required": true,
+ "type": "string"
+ }
+ ],
+ "responses": {
+ "200": {
+ "description": "200 OK\nThe list of subscriptions was queried successfully. The representations body shall contain in an array the representations of all active subscriptions of the functional block that invokes the method , i.e. zero or more representations of VNF package Management subscriptions as defined in clause 10.5.2.4. If the VNFM supports alternative 2 (paging) according to clause 4.7.2.1 for this resource, inclusion of the Link HTTP header in this response shall follow the provisions in clause 4.7.2.3.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ },
+ "Link": {
+ "description": "Reference to other resources. Used for paging in the present document, see clause 4.7.2.1.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ }
+ },
+ "schema": {
+ "type": "array",
+ "items": {
+ "description": "This type represents a subscription related to notifications about VNF package management.\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 related to VNF package management. 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": {
+ "notificationTypes": {
+ "description": "Match particular notification types. Permitted values: - VnfPackageOnboardingNotification - VnfPackageChangeNotification The permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the notification types to facilitate automated code generation systems.\n",
+ "type": "array",
+ "items": {
+ "type": "string",
+ "enum": [
+ "VnfPackageOnboardingNotification",
+ "VnfPackageChangeNotification"
+ ]
+ }
+ },
+ "vnfProductsFromProviders": {
+ "description": "If present, match VNF packages that contain VNF products from certain providers. The attributes \"vnfProductsFromProviders\", \"vnfdId\" and \"vnfPkgId\" are alternatives to reference to particular VNF packages 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 packages that contain 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 packages that contain 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 packages that contain 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"
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ },
+ "vnfdId": {
+ "description": "Match VNF packages with a VNFD identifier listed in the attribute. The attributes \"vnfProductsFromProviders\", \"vnfdId\" and \"vnfPkgId\" are alternatives to reference to particular VNF packages 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"
+ }
+ },
+ "vnfPkgId": {
+ "description": "Match VNF packages with a package identifier listed in the attribute. May be present if the \"notificationTypes\" attribute contains the value \"VnfPackageChangeNotification\", and shall be absent otherwise. The attributes \"vnfProductsFromProviders\", \"vnfdId\" and \"vnfPkgId\" are alternatives to reference to particular VNF packages 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"
+ }
+ },
+ "operationalState": {
+ "description": "- ENABLED: The VNF package is enabled, i.e. it can be used for instantiation of new VNF instances.\n- DISABLED: The VNF package is disabled, i.e. it cannot be used for further VNF instantiation requests (unless and until the VNF package\n is re-enabled).\n",
+ "type": "string",
+ "enum": [
+ "ENABLED",
+ "DISABLED"
+ ]
+ },
+ "usageState": {
+ "description": "- IN_USE: VNF instances instantiated from this VNF package exist. - NOT_IN_USE: No existing VNF instance is instantiated from this VNF package.\n"
+ }
+ }
+ },
+ "callbackUri": {
+ "description": "String formatted according to IETF RFC 3986.\n",
+ "type": "string"
+ },
+ "_links": {
+ "description": "Links to resources related to this resource.\n",
+ "type": "object",
+ "required": [
+ "self"
+ ],
+ "properties": {
+ "self": {
+ "description": "This type represents a link to a resource using an absolute URI. It shall comply with the provisions defined in table 4.4.1.3-1.\n",
+ "type": "object",
+ "required": [
+ "href"
+ ],
+ "properties": {
+ "href": {
+ "description": "String formatted according to IETF RFC 3986.\n",
+ "type": "string"
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ },
+ "400": {
+ "description": "400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), 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.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it 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.\nIf 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.\nIf 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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "401": {
+ "description": "401 UNAUTHORIZED\nIf 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "403": {
+ "description": "403 FORBIDDEN\nIf 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "404": {
+ "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "405": {
+ "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "406": {
+ "description": "406 NOT ACCEPTABLE\nIf the \"Accept\" 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "416": {
+ "description": "416 RANGE NOT SATISFIABLE\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "500": {
+ "description": "500 INTERNAL SERVER ERROR\nIf 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 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "503": {
+ "description": "503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ }
+ }
+ }
+ },
+ "/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.\n",
+ "in": "path",
+ "type": "string",
+ "required": true
+ }
+ ],
+ "get": {
+ "description": "Query Subscription Information\n\nThe GET method reads an individual subscription.\n",
+ "parameters": [
+ {
+ "name": "Accept",
+ "description": "Content-Types that are acceptable for the response. Reference: IETF RFC 7231\n",
+ "in": "header",
+ "required": true,
+ "type": "string"
+ },
+ {
+ "name": "Authorization",
+ "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
+ "in": "header",
+ "required": false,
+ "type": "string"
+ },
+ {
+ "name": "Version",
+ "description": "Version of the API requested to use when responding to this request.\n",
+ "in": "header",
+ "required": true,
+ "type": "string"
+ }
+ ],
+ "responses": {
+ "200": {
+ "description": "200 OK\nRepresentation of the subscription resource.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ },
+ "schema": {
+ "description": "This type represents a subscription related to notifications about VNF package management.\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 related to VNF package management. 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": {
+ "notificationTypes": {
+ "description": "Match particular notification types. Permitted values: - VnfPackageOnboardingNotification - VnfPackageChangeNotification The permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the notification types to facilitate automated code generation systems.\n",
+ "type": "array",
+ "items": {
+ "type": "string",
+ "enum": [
+ "VnfPackageOnboardingNotification",
+ "VnfPackageChangeNotification"
+ ]
+ }
+ },
+ "vnfProductsFromProviders": {
+ "description": "If present, match VNF packages that contain VNF products from certain providers. The attributes \"vnfProductsFromProviders\", \"vnfdId\" and \"vnfPkgId\" are alternatives to reference to particular VNF packages 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 packages that contain 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 packages that contain 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 packages that contain 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"
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ },
+ "vnfdId": {
+ "description": "Match VNF packages with a VNFD identifier listed in the attribute. The attributes \"vnfProductsFromProviders\", \"vnfdId\" and \"vnfPkgId\" are alternatives to reference to particular VNF packages 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"
+ }
+ },
+ "vnfPkgId": {
+ "description": "Match VNF packages with a package identifier listed in the attribute. May be present if the \"notificationTypes\" attribute contains the value \"VnfPackageChangeNotification\", and shall be absent otherwise. The attributes \"vnfProductsFromProviders\", \"vnfdId\" and \"vnfPkgId\" are alternatives to reference to particular VNF packages 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"
+ }
+ },
+ "operationalState": {
+ "description": "- ENABLED: The VNF package is enabled, i.e. it can be used for instantiation of new VNF instances.\n- DISABLED: The VNF package is disabled, i.e. it cannot be used for further VNF instantiation requests (unless and until the VNF package\n is re-enabled).\n",
+ "type": "string",
+ "enum": [
+ "ENABLED",
+ "DISABLED"
+ ]
+ },
+ "usageState": {
+ "description": "- IN_USE: VNF instances instantiated from this VNF package exist. - NOT_IN_USE: No existing VNF instance is instantiated from this VNF package.\n"
+ }
+ }
+ },
+ "callbackUri": {
+ "description": "String formatted according to IETF RFC 3986.\n",
+ "type": "string"
+ },
+ "_links": {
+ "description": "Links to resources related to this resource.\n",
+ "type": "object",
+ "required": [
+ "self"
+ ],
+ "properties": {
+ "self": {
+ "description": "This type represents a link to a resource using an absolute URI. It shall comply with the provisions defined in table 4.4.1.3-1.\n",
+ "type": "object",
+ "required": [
+ "href"
+ ],
+ "properties": {
+ "href": {
+ "description": "String formatted according to IETF RFC 3986.\n",
+ "type": "string"
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ },
+ "400": {
+ "description": "400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), 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.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it 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.\nIf 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.\nIf 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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "401": {
+ "description": "401 UNAUTHORIZED\nIf 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "403": {
+ "description": "403 FORBIDDEN\nIf 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "404": {
+ "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "405": {
+ "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "406": {
+ "description": "406 NOT ACCEPTABLE\nIf the \"Accept\" 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "416": {
+ "description": "416 RANGE NOT SATISFIABLE\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "500": {
+ "description": "500 INTERNAL SERVER ERROR\nIf 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 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "503": {
+ "description": "503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ }
+ }
+ },
+ "delete": {
+ "description": "Terminate subscription\n\nThe DELETE method terminates an individual subscription.\n",
+ "parameters": [
+ {
+ "name": "Authorization",
+ "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
+ "in": "header",
+ "required": false,
+ "type": "string"
+ },
+ {
+ "name": "Version",
+ "description": "Version of the API requested to use when responding to this request.\n",
+ "in": "header",
+ "required": true,
+ "type": "string"
+ }
+ ],
+ "responses": {
+ "204": {
+ "description": "204 NO CONTENT\nThe subscription resource was deleted successfully.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ }
+ },
+ "400": {
+ "description": "400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), 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.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it 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.\nIf 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.\nIf 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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "401": {
+ "description": "401 UNAUTHORIZED\nIf 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "403": {
+ "description": "403 FORBIDDEN\nIf 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "404": {
+ "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "405": {
+ "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "406": {
+ "description": "406 NOT ACCEPTABLE\nIf the \"Accept\" 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "416": {
+ "description": "416 RANGE NOT SATISFIABLE\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "500": {
+ "description": "500 INTERNAL SERVER ERROR\nIf 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 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "503": {
+ "description": "503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+}
\ No newline at end of file
diff --git a/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-api/src/main/resources/SOL003-VNFPackageManagement-Notification-API.json b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-api/src/main/resources/SOL003-VNFPackageManagement-Notification-API.json
new file mode 100644
index 0000000..32e002f
--- /dev/null
+++ b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-api/src/main/resources/SOL003-VNFPackageManagement-Notification-API.json
@@ -0,0 +1,1778 @@
+{
+ "swagger": "2.0",
+ "info": {
+ "version": "1.2.0-impl:etsi.org:ETSI_NFV_OpenAPI:1",
+ "title": "SOL003 - VNF Package Management Notification interface",
+ "description": "SOL003 - VNF Package Management Notification interface\n\nIMPORTANT: 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.\n\nIn 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.\nPlease report bugs to https://forge.etsi.org/bugzilla/buglist.cgi?component=Nfv-Openapis&list_id=61&product=NFV&resolution=\n",
+ "license": {
+ "name": "ETSI Forge copyright notice",
+ "url": "https://forge.etsi.org/etsi-forge-copyright-notice.txt"
+ }
+ },
+ "externalDocs": {
+ "description": "ETSI GS NFV-SOL 003 V2.5.1",
+ "url": "https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/02.05.01_60/gs_nfv-sol003v020501p.pdf"
+ },
+ "basePath": "/callback/v1",
+ "schemes": ["https"],
+ "consumes": ["application/json"],
+ "produces": ["application/json"],
+ "paths": {
+ "/URI-is-provided-by-the-client-when-creating-the-subscription-VnfPackageOnboardingNotification": {
+ "post": {
+ "description": "Notify\n\nThe POST method delivers a notification from the server to the client.\n",
+ "parameters": [{
+ "name": "VnfPackageOnboardingNotification",
+ "description": "A notification about on-boarding of a VNF package.",
+ "in": "body",
+ "required": true,
+ "schema": {
+ "description": "This type represents a VNF package management notification, which informs the receiver that the onboarding process of a VNF package is complete and the package is ready for use. The notification shall be triggered by the NFVO when the \"onboardingState\" attribute of a new VNF package has changed to \"ONBOARDED\".\n",
+ "type": "object",
+ "required": ["id", "notificationType", "subscriptionId", "timeStamp", "vnfPkgId", "vnfdId", "_links"],
+ "properties": {
+ "id": {
+ "description": "An identifier with the intention of being globally unique.\n",
+ "type": "string"
+ },
+ "notificationType": {
+ "description": "Discriminator for the different notification types. Shall be set to \"VnfPackageOnboardingNotification\" for this notification type.\n",
+ "type": "string",
+ "enum": ["VnfPackageOnboardingNotification"]
+ },
+ "subscriptionId": {
+ "description": "An identifier with the intention of being globally unique.\n",
+ "type": "string"
+ },
+ "timeStamp": {
+ "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "vnfPkgId": {
+ "description": "An identifier with the intention of being globally unique.\n",
+ "type": "string"
+ },
+ "vnfdId": {
+ "description": "An identifier with the intention of being globally unique.\n",
+ "type": "string"
+ },
+ "_links": {
+ "description": "This type represents the links to resources that a VNF package management notification can contain.\n",
+ "type": "object",
+ "required": ["vnfPackage", "subscription"],
+ "properties": {
+ "vnfPackage": {
+ "description": "This type represents a link to a resource in a notification, using an absolute or relative URI. It shall comply with the provisions defined in table 4.4.1.3a-1.\n",
+ "type": "object",
+ "required": ["href"],
+ "properties": {
+ "href": {
+ "description": "String formatted according to IETF RFC 3986.\n",
+ "type": "string"
+ }
+ }
+ },
+ "subscription": {
+ "description": "This type represents a link to a resource in a notification, using an absolute or relative URI. It shall comply with the provisions defined in table 4.4.1.3a-1.\n",
+ "type": "object",
+ "required": ["href"],
+ "properties": {
+ "href": {
+ "description": "String formatted according to IETF RFC 3986.\n",
+ "type": "string"
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ }, {
+ "name": "Authorization",
+ "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
+ "in": "header",
+ "required": false,
+ "type": "string"
+ }, {
+ "name": "Content-Type",
+ "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n",
+ "in": "header",
+ "required": true,
+ "type": "string"
+ }, {
+ "name": "Version",
+ "description": "Version of the API requested to use when responding to this request.\n",
+ "in": "header",
+ "required": true,
+ "type": "string"
+ }],
+ "responses": {
+ "204": {
+ "description": "204 NO CONTENT\nThe notification was delivered successfully.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ }
+ },
+ "400": {
+ "description": "400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), 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.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it 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.\nIf 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.\nIf 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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "401": {
+ "description": "401 UNAUTHORIZED\nIf 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "403": {
+ "description": "403 FORBIDDEN\nIf 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "404": {
+ "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "406": {
+ "description": "406 NOT ACCEPTABLE\nIf the \"Accept\" 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "500": {
+ "description": "500 INTERNAL SERVER ERROR\nIf 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 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "503": {
+ "description": "503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ }
+ }
+ },
+ "get": {
+ "description": "The GET method allows the server to test the notification endpoint that is provided by the client, e.g. during subscription.\n",
+ "parameters": [{
+ "name": "Authorization",
+ "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
+ "in": "header",
+ "required": false,
+ "type": "string"
+ }, {
+ "name": "Version",
+ "description": "Version of the API requested to use when responding to this request.\n",
+ "in": "header",
+ "required": true,
+ "type": "string"
+ }],
+ "responses": {
+ "204": {
+ "description": "204 NO CONTENT\nThe notification endpoint was tested successfully. The response body shall be empty.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ }
+ },
+ "400": {
+ "description": "400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), 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.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it 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.\nIf 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.\nIf 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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "401": {
+ "description": "401 UNAUTHORIZED\nIf 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "403": {
+ "description": "403 FORBIDDEN\nIf 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "404": {
+ "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "406": {
+ "description": "406 NOT ACCEPTABLE\nIf the \"Accept\" 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "500": {
+ "description": "500 INTERNAL SERVER ERROR\nIf 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 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "503": {
+ "description": "503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ }
+ }
+ }
+ },
+ "/URI-is-provided-by-the-client-when-creating-the-subscription-VnfPackageChangeNotification": {
+ "post": {
+ "description": "Notify\n\nThe POST method delivers a notification from the server to the client.\n",
+ "parameters": [{
+ "name": "VnfPackageChangeNotification",
+ "description": "A notification about changes of status in a VNF package.\n",
+ "in": "body",
+ "required": true,
+ "schema": {
+ "description": "This type represents a VNF package management notification, which informs the receiver of a change of the status in an on-boarded VNF package. Only changes in the \"operationalState\" attribute of an on-boarded VNF package and the deletion NF package will be reported. Changes in the \"usageState\" and \"onboardingState\" attributes are not reported. The notification shall be triggered by the NFVO when there is a change in the status of an onboarded VNF package, as follows: * The \"operationalState\" attribute of a VNF package has changed, and the \"onboardingState\" attribute of the package has the value \"ONBOARDED\"\n (i.e. the package has been onboarded previously).\n* The on-boarded VNF package has been deleted.\n",
+ "type": "object",
+ "required": ["id", "notificationType", "subscriptionId", "timeStamp", "vnfPkgId", "vnfdId", "changeType", "_links"],
+ "properties": {
+ "id": {
+ "description": "An identifier with the intention of being globally unique.\n",
+ "type": "string"
+ },
+ "notificationType": {
+ "description": "Discriminator for the different notification types. Shall be set to \"VnfPackageChangeNotification\" for this notification type.\n",
+ "type": "string",
+ "enum": ["VnfPackageChangeNotification"]
+ },
+ "subscriptionId": {
+ "description": "An identifier with the intention of being globally unique.\n",
+ "type": "string"
+ },
+ "timeStamp": {
+ "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "vnfPkgId": {
+ "description": "An identifier with the intention of being globally unique.\n",
+ "type": "string"
+ },
+ "vnfdId": {
+ "description": "An identifier with the intention of being globally unique.\n",
+ "type": "string"
+ },
+ "changeType": {
+ "description": "- OP_STATE_CHANGE: The \"operationalState\" attribute has been changed. - PKG_DELETE: The VNF package has been deleted.\n",
+ "type": "string",
+ "enum": ["OP_STATE_CHANGE", "PKG_DELETE"]
+ },
+ "operationalState": {
+ "description": "- ENABLED: The VNF package is enabled, i.e. it can be used for instantiation of new VNF instances.\n- DISABLED: The VNF package is disabled, i.e. it cannot be used for further VNF instantiation requests (unless and until the VNF package\n is re-enabled).\n",
+ "type": "string",
+ "enum": ["ENABLED", "DISABLED"]
+ },
+ "_links": {
+ "description": "This type represents the links to resources that a VNF package management notification can contain.\n",
+ "type": "object",
+ "required": ["vnfPackage", "subscription"],
+ "properties": {
+ "vnfPackage": {
+ "description": "This type represents a link to a resource in a notification, using an absolute or relative URI. It shall comply with the provisions defined in table 4.4.1.3a-1.\n",
+ "type": "object",
+ "required": ["href"],
+ "properties": {
+ "href": {
+ "description": "String formatted according to IETF RFC 3986.\n",
+ "type": "string"
+ }
+ }
+ },
+ "subscription": {
+ "description": "This type represents a link to a resource in a notification, using an absolute or relative URI. It shall comply with the provisions defined in table 4.4.1.3a-1.\n",
+ "type": "object",
+ "required": ["href"],
+ "properties": {
+ "href": {
+ "description": "String formatted according to IETF RFC 3986.\n",
+ "type": "string"
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ }, {
+ "name": "Authorization",
+ "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
+ "in": "header",
+ "required": false,
+ "type": "string"
+ }, {
+ "name": "Content-Type",
+ "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n",
+ "in": "header",
+ "required": true,
+ "type": "string"
+ }, {
+ "name": "Version",
+ "description": "Version of the API requested to use when responding to this request.\n",
+ "in": "header",
+ "required": true,
+ "type": "string"
+ }],
+ "responses": {
+ "204": {
+ "description": "204 NO CONTENT\nThe notification was delivered successfully.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ }
+ },
+ "400": {
+ "description": "400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), 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.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it 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.\nIf 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.\nIf 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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "401": {
+ "description": "401 UNAUTHORIZED\nIf 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "403": {
+ "description": "403 FORBIDDEN\nIf 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "404": {
+ "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "406": {
+ "description": "406 NOT ACCEPTABLE\nIf the \"Accept\" 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "500": {
+ "description": "500 INTERNAL SERVER ERROR\nIf 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 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "503": {
+ "description": "503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ }
+ }
+ },
+ "get": {
+ "description": "The GET method allows the server to test the notification endpoint that is provided by the client, e.g. during subscription.\n",
+ "parameters": [{
+ "name": "Authorization",
+ "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
+ "in": "header",
+ "required": false,
+ "type": "string"
+ }, {
+ "name": "Version",
+ "description": "Version of the API requested to use when responding to this request.\n",
+ "in": "header",
+ "required": true,
+ "type": "string"
+ }],
+ "responses": {
+ "204": {
+ "description": "204 NO CONTENT\nThe notification endpoint was tested successfully. The response body shall be empty.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ }
+ },
+ "400": {
+ "description": "400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), 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.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it 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.\nIf 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.\nIf 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.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "401": {
+ "description": "401 UNAUTHORIZED\nIf 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "403": {
+ "description": "403 FORBIDDEN\nIf 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "404": {
+ "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "406": {
+ "description": "406 NOT ACCEPTABLE\nIf the \"Accept\" 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "500": {
+ "description": "500 INTERNAL SERVER ERROR\nIf 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 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.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "503": {
+ "description": "503 SERVICE UNAVAILABLE\nIf 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 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n",
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ },
+ "Version": {
+ "description": "Version of the API used in the response.\n",
+ "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].\n",
+ "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\".\n",
+ "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).\n",
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+}
\ No newline at end of file
diff --git a/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/pom.xml b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/pom.xml
index aefea95..00fd81f 100644
--- a/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/pom.xml
+++ b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/pom.xml
@@ -18,6 +18,16 @@
<groupId>org.onap.so.adapters</groupId>
<artifactId>mso-vnfm-adapter-ext-clients</artifactId>
<version>1.4.3</version>
+ <exclusions>
+ <exclusion>
+ <groupId>javax.servlet</groupId>
+ <artifactId>javax.servlet-api</artifactId>
+ </exclusion>
+ <exclusion>
+ <groupId>com.github.tomakehurst</groupId>
+ <artifactId>wiremock-standalone</artifactId>
+ </exclusion>
+ </exclusions>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
@@ -109,6 +119,22 @@
<groupId>org.onap.so</groupId>
<artifactId>common</artifactId>
<version>1.4.3</version>
+ <exclusions>
+ <exclusion>
+ <groupId>javax.servlet</groupId>
+ <artifactId>javax.servlet-api</artifactId>
+ </exclusion>
+ </exclusions>
+ </dependency>
+ <dependency>
+ <groupId>org.onap.so.simulators.vnfm</groupId>
+ <artifactId>vnfm-api</artifactId>
+ <version>${project.version}</version>
+ </dependency>
+ <dependency>
+ <groupId>org.apache.httpcomponents</groupId>
+ <artifactId>httpclient</artifactId>
+ <version>4.5.8</version>
</dependency>
</dependencies>
<build>
diff --git a/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/java/org/onap/so/svnfm/simulator/config/SslBasedRestTemplateConfiguration.java b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/java/org/onap/so/svnfm/simulator/config/SslBasedRestTemplateConfiguration.java
new file mode 100644
index 0000000..47e189d
--- /dev/null
+++ b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/java/org/onap/so/svnfm/simulator/config/SslBasedRestTemplateConfiguration.java
@@ -0,0 +1,105 @@
+/*-
+ * ============LICENSE_START=======================================================
+ * Copyright (C) 2020 Nordix Foundation.
+ * ================================================================================
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ *
+ * SPDX-License-Identifier: Apache-2.0
+ * ============LICENSE_END=========================================================
+ */
+package org.onap.so.svnfm.simulator.config;
+
+import com.google.gson.Gson;
+import org.apache.http.client.HttpClient;
+import org.apache.http.conn.ssl.SSLConnectionSocketFactory;
+import org.apache.http.impl.client.HttpClientBuilder;
+import org.apache.http.impl.client.HttpClients;
+import org.apache.http.ssl.SSLContextBuilder;
+import org.onap.so.adapters.vnfmadapter.extclients.vnfm.JSON;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+import org.springframework.beans.factory.annotation.Qualifier;
+import org.springframework.beans.factory.annotation.Value;
+import org.springframework.context.annotation.Bean;
+import org.springframework.context.annotation.Configuration;
+import org.springframework.core.io.Resource;
+import org.springframework.http.client.HttpComponentsClientHttpRequestFactory;
+import org.springframework.http.converter.HttpMessageConverter;
+import org.springframework.http.converter.json.GsonHttpMessageConverter;
+import org.springframework.http.converter.json.MappingJackson2HttpMessageConverter;
+import org.springframework.web.client.RestTemplate;
+import java.security.KeyStore;
+import java.util.Iterator;
+
+/**
+ * @author Waqas Ikram (waqas.ikram@est.tech)
+ * @author Andrew Lamb (andrew.a.lamb@est.tech)
+ */
+@Configuration public class SslBasedRestTemplateConfiguration {
+
+ private static final Logger logger = LoggerFactory.getLogger(SslBasedRestTemplateConfiguration.class);
+
+ public static final String SSL_BASED_CONFIGURABLE_REST_TEMPLATE = "sslBasedConfigurableRestTemplate";
+
+ @Value("${http.client.ssl.trust-store:#{null}}")
+ private Resource trustStore;
+ @Value("${http.client.ssl.trust-store-password:#{null}}")
+ private String trustStorePassword;
+
+ @Value("${server.ssl.key-store:#{null}}")
+ private Resource keyStoreResource;
+ @Value("${server.ssl.key--store-password:#{null}}")
+ private String keyStorePassword;
+
+ @Bean
+ @Qualifier(SSL_BASED_CONFIGURABLE_REST_TEMPLATE)
+ public RestTemplate sslBasedrestTemplate() throws Exception {
+ logger.info("Configuring {} ...", this.getClass().getCanonicalName());
+ final RestTemplate restTemplate = new RestTemplate();
+ final HttpClientBuilder builder = HttpClients.custom();
+
+ if (keyStoreResource != null && trustStore != null) {
+ logger.info("Setting key-store: {}", keyStoreResource.getURL());
+ logger.info("Setting key-store-password: {}", keyStorePassword);
+ final KeyStore keystore = KeyStore.getInstance("pkcs12");
+ keystore.load(keyStoreResource.getInputStream(), keyStorePassword.toCharArray());
+
+ logger.info("Setting client trust-store: {}", trustStore.getURL());
+ logger.info("Setting client trust-store-password: {}", trustStorePassword);
+ final SSLConnectionSocketFactory socketFactory = new SSLConnectionSocketFactory(
+ new SSLContextBuilder().loadTrustMaterial(trustStore.getURL(), trustStorePassword.toCharArray())
+ .loadKeyMaterial(keystore, keyStorePassword.toCharArray()).build());
+ builder.setSSLSocketFactory(socketFactory);
+ }
+
+ final HttpClient httpClient = builder.build();
+ final HttpComponentsClientHttpRequestFactory factory = new HttpComponentsClientHttpRequestFactory(httpClient);
+ restTemplate.setRequestFactory(factory);
+ setGsonMessageConverter(restTemplate);
+ return restTemplate;
+ }
+
+ public void setGsonMessageConverter(final RestTemplate restTemplate) {
+ logger.info("Setting GsonMessageConverter ...");
+ final Iterator<HttpMessageConverter<?>> iterator = restTemplate.getMessageConverters().iterator();
+ while (iterator.hasNext()) {
+ if (iterator.next() instanceof MappingJackson2HttpMessageConverter) {
+ iterator.remove();
+ }
+ }
+ final Gson gson = new JSON().getGson();
+ restTemplate.getMessageConverters().add(new GsonHttpMessageConverter(gson));
+ logger.info("Finished setting GsonMessageConverter ...");
+ }
+
+}
diff --git a/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/java/org/onap/so/svnfm/simulator/constants/Constant.java b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/java/org/onap/so/svnfm/simulator/constants/Constant.java
index 02a319a..ceb5be5 100644
--- a/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/java/org/onap/so/svnfm/simulator/constants/Constant.java
+++ b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/java/org/onap/so/svnfm/simulator/constants/Constant.java
@@ -24,6 +24,7 @@
*
* @author Lathishbabu Ganesan (lathishbabu.ganesan@est.tech)
* @author ronan.kenny@est.tech
+ * @author Eoin Hanan (eoin.hanan@est.tech)
*/
public class Constant {
@@ -36,4 +37,9 @@
public static final String VNF_CONFIG_PROPERTIES =
"{\"isAutoScaleEnabled\": \"true\",\"isAutoHealingEnabled\": \"true\"}";
public static final String IN_LINE_RESPONSE_201_CACHE = "inlineResponse201";
+ public static final String PACKAGE_MANAGEMENT_BASE_URL = "/vnfpkgm/v1";
+ public static final String SUBSCRIPTION_ENDPOINT = "/subscribe";
+ public static final String NOTIFICATION_ENDPOINT = "/notification";
+ public static final String VNFM_ADAPTER_ENDPOINT = "https://so-vnfm-adapter.onap:9092/so/vnfm-adapter/v1/";
+ public static final String VNFM_ADAPTER_SUBSCRIPTION_ENDPOINT = VNFM_ADAPTER_ENDPOINT + "vnfpkgm/v1/subscriptions";
}
diff --git a/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/java/org/onap/so/svnfm/simulator/controller/SubscriptionNotificationController.java b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/java/org/onap/so/svnfm/simulator/controller/SubscriptionNotificationController.java
new file mode 100644
index 0000000..2c6b8f2
--- /dev/null
+++ b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/java/org/onap/so/svnfm/simulator/controller/SubscriptionNotificationController.java
@@ -0,0 +1,107 @@
+/*-
+ * ============LICENSE_START=======================================================
+ * Copyright (C) 2020 Nordix Foundation.
+ * ================================================================================
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ *
+ * SPDX-License-Identifier: Apache-2.0
+ * ============LICENSE_END=========================================================
+ */
+
+package org.onap.so.svnfm.simulator.controller;
+
+import javax.ws.rs.core.MediaType;
+import org.onap.so.adapters.vnfmadapter.extclients.vnfm.packagemanagement.model.InlineResponse201;
+import org.onap.so.adapters.vnfmadapter.extclients.vnfm.packagemanagement.model.PkgmSubscriptionRequest;
+import org.onap.so.adapters.vnfmadapter.extclients.vnfm.packagemanagement.model.SubscriptionsAuthentication;
+import org.onap.so.adapters.vnfmadapter.extclients.vnfm.packagemanagement.model.SubscriptionsAuthentication.AuthTypeEnum;
+import org.onap.so.adapters.vnfmadapter.extclients.vnfm.packagemanagement.model.SubscriptionsAuthenticationParamsBasic;
+import org.onap.so.svnfm.simulator.constants.Constant;
+import org.onap.so.svnfm.simulator.services.SubscriptionManager;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+import org.springframework.beans.factory.annotation.Autowired;
+import org.springframework.beans.factory.annotation.Value;
+import org.springframework.http.ResponseEntity;
+import org.springframework.web.bind.annotation.GetMapping;
+import org.springframework.web.bind.annotation.PostMapping;
+import org.springframework.web.bind.annotation.RequestBody;
+import org.springframework.web.bind.annotation.RequestMapping;
+import org.springframework.web.bind.annotation.RestController;
+
+/**
+ * @author Eoin Hanan (eoin.hanan@est.tech)
+ * @author Andrew Lamb (andrew.a.lamb@est.tech)
+ *
+ */
+@RestController
+@RequestMapping(path = Constant.PACKAGE_MANAGEMENT_BASE_URL, produces = MediaType.APPLICATION_JSON, consumes = MediaType.APPLICATION_JSON)
+public class SubscriptionNotificationController {
+ @Autowired
+ private SubscriptionManager subscriptionManager;
+
+ private static final Logger logger = LoggerFactory.getLogger(SubscriptionNotificationController.class);
+
+ @Value("${spring.security.usercredentials[0].username}")
+ private String username;
+ @Value("${spring.security.usercredentials[0].password}")
+ private String password;
+
+ @GetMapping(produces = {MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})
+ public ResponseEntity<Void> testEndpoint() {
+ logger.info("Testing SubscriptionNotification Endpoint");
+ return ResponseEntity.noContent().build();
+ }
+
+ /**
+ * Send subscription request
+ *
+ * @param pkgmSubscriptionRequest The subscription request
+ * @return
+ */
+ @PostMapping(value = Constant.SUBSCRIPTION_ENDPOINT, produces = {MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})
+ public ResponseEntity<?> subscribeForNotifications(@RequestBody final PkgmSubscriptionRequest pkgmSubscriptionRequest){
+ logger.info("Vnf Package Subscription Request received:\n{}", pkgmSubscriptionRequest);
+
+ if(pkgmSubscriptionRequest.getCallbackUri()==null){
+ logger.info("Subscription Request does not include call back URI ");
+ pkgmSubscriptionRequest.setCallbackUri(Constant.PACKAGE_MANAGEMENT_BASE_URL + Constant.NOTIFICATION_ENDPOINT);
+ }
+
+ if(pkgmSubscriptionRequest.getAuthentication()==null) {
+ pkgmSubscriptionRequest.setAuthentication(new SubscriptionsAuthentication()
+ .addAuthTypeItem(AuthTypeEnum.BASIC)
+ .paramsBasic(new SubscriptionsAuthenticationParamsBasic().userName(username).password(password)));
+
+ }
+ logger.info("Final Request being sent:\n{}", pkgmSubscriptionRequest);
+
+ final InlineResponse201 response = subscriptionManager.createSubscription(pkgmSubscriptionRequest);
+ logger.info("Response is:\n{}", response);
+
+ return ResponseEntity.ok().body(response);
+ }
+
+ /**
+ * Endpoint to receive VNF package notifications
+ *
+ * @param notification The notification received
+ * @return
+ */
+ @PostMapping(value = Constant.NOTIFICATION_ENDPOINT, produces = {MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})
+ public ResponseEntity<?> postVnfPackageNotification(@RequestBody Object notification){
+ logger.info("Vnf Notification received:\n{}", notification);
+ return ResponseEntity.noContent().build();
+ }
+
+}
diff --git a/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/java/org/onap/so/svnfm/simulator/controller/SvnfmController.java b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/java/org/onap/so/svnfm/simulator/controller/SvnfmController.java
index 6683b69..ce3ee8f 100644
--- a/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/java/org/onap/so/svnfm/simulator/controller/SvnfmController.java
+++ b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/java/org/onap/so/svnfm/simulator/controller/SvnfmController.java
@@ -65,7 +65,7 @@
/**
* To create the Vnf and stores the response in cache
*
- * @param CreateVnfRequest
+ * @param createVNFRequest
* @return InlineResponse201
*/
@PostMapping(value = "/vnf_instances")
diff --git a/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/java/org/onap/so/svnfm/simulator/oauth/AuthorizationServerConfig.java b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/java/org/onap/so/svnfm/simulator/oauth/AuthorizationServerConfig.java
index 500c85b..a97c41f 100644
--- a/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/java/org/onap/so/svnfm/simulator/oauth/AuthorizationServerConfig.java
+++ b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/java/org/onap/so/svnfm/simulator/oauth/AuthorizationServerConfig.java
@@ -20,7 +20,7 @@
@Override
public void configure(final ClientDetailsServiceConfigurer clients) throws Exception {
clients.inMemory().withClient("vnfmadapter")
- .secret("$2a$10$dHzTlqSBcm8hdO52LBvnX./zNTvUzzJy.lZrc4bCBL5gkln0wX6T6")
+ .secret("$2a$10$dHzTlqSBcm8hdO52LBvnX./zNTvUzzJy.lZrc4bCBL5gkln0wX6T6") //123456
.authorizedGrantTypes("client_credentials").scopes("write").accessTokenValiditySeconds(ONE_DAY)
.refreshTokenValiditySeconds(ONE_DAY);
}
diff --git a/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/java/org/onap/so/svnfm/simulator/services/SubscriptionManager.java b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/java/org/onap/so/svnfm/simulator/services/SubscriptionManager.java
new file mode 100644
index 0000000..2050ab0
--- /dev/null
+++ b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/java/org/onap/so/svnfm/simulator/services/SubscriptionManager.java
@@ -0,0 +1,70 @@
+package org.onap.so.svnfm.simulator.services;
+
+import static org.onap.so.svnfm.simulator.config.SslBasedRestTemplateConfiguration.SSL_BASED_CONFIGURABLE_REST_TEMPLATE;
+
+import java.nio.charset.StandardCharsets;
+import javax.ws.rs.core.MediaType;
+import org.apache.commons.codec.binary.Base64;
+import org.onap.so.adapters.vnfmadapter.extclients.vnfm.packagemanagement.model.InlineResponse201;
+import org.onap.so.adapters.vnfmadapter.extclients.vnfm.packagemanagement.model.PkgmSubscriptionRequest;
+import org.onap.so.svnfm.simulator.constants.Constant;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+import org.springframework.beans.factory.annotation.Autowired;
+import org.springframework.beans.factory.annotation.Qualifier;
+import org.springframework.beans.factory.annotation.Value;
+import org.springframework.http.HttpEntity;
+import org.springframework.http.HttpHeaders;
+import org.springframework.http.HttpMethod;
+import org.springframework.stereotype.Service;
+import org.springframework.web.client.RestTemplate;
+
+/**
+ *
+ * @author Eoin Hanan (eoin.hanan@est.tech)
+ * @author Gareth Roper (gareth.roper@est.tech)
+ */
+@Service
+public class SubscriptionManager {
+
+ private static final Logger LOGGER = LoggerFactory.getLogger(SubscriptionManager.class);
+
+ private final RestTemplate restTemplate;
+
+ @Value("${vnfm-adapter.auth.name}")
+ private String username;
+
+ @Value("${vnfm-adapter.auth.password}")
+ private String password;
+
+ @Autowired
+ public SubscriptionManager(
+ @Qualifier(SSL_BASED_CONFIGURABLE_REST_TEMPLATE) final RestTemplate restTemplate) {
+ this.restTemplate = restTemplate;
+ }
+
+ /**
+ * Send subscription request to the vnfm adapter
+ *
+ * @param pkgmSubscriptionRequest The subscription request to send
+ * @return
+ */
+ public InlineResponse201 createSubscription(final PkgmSubscriptionRequest pkgmSubscriptionRequest) {
+ final byte[] encodedAuth = getBasicAuth(username, password);
+ final String authHeader = "Basic " + new String(encodedAuth);
+ final String uri = Constant.VNFM_ADAPTER_SUBSCRIPTION_ENDPOINT;
+ final HttpHeaders headers = new HttpHeaders();
+ headers.add(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_JSON);
+ headers.add(HttpHeaders.AUTHORIZATION, authHeader);
+ headers.add(HttpHeaders.ACCEPT, MediaType.APPLICATION_JSON);
+ final HttpEntity<?> request = new HttpEntity<>(pkgmSubscriptionRequest, headers);
+ LOGGER.info("Creating Subscription using request: {}", pkgmSubscriptionRequest);
+ return restTemplate.exchange(uri, HttpMethod.POST, request, InlineResponse201.class).getBody();
+ }
+
+ private byte[] getBasicAuth(final String username, final String password) {
+ final String auth = username + ":" + password;
+ return Base64.encodeBase64(auth.getBytes(StandardCharsets.ISO_8859_1));
+ }
+
+}
diff --git a/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/resources/application.yaml b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/resources/application.yaml
index 33d865c..ffae8eb 100644
--- a/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/resources/application.yaml
+++ b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/resources/application.yaml
@@ -11,54 +11,64 @@
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
-
spring:
- h2:
- console:
- enabled: true
- path: console
- datasource:
- url: jdbc:h2:mem:testdb;DB_CLOSE_ON_EXIT=FALSE
- username: admin
- password: admin
- http:
- converters:
- preferred-json-mapper: gson
- security:
- usercredentials:
- - username: vnfm
- password: '$2a$10$Fh9ffgPw2vnmsghsRD3ZauBL1aKXebigbq3BB1RPWtE62UDILsjke'
- role: BPEL-Client
-
+ h2:
+ console: null
+ enabled: true
+ path: console
+ datasource:
+ url: jdbc:h2:mem:testdb;DB_CLOSE_ON_EXIT=FALSE
+ username: admin
+ password: admin
+ http:
+ converters:
+ preferred-json-mapper: gson
+ security:
+ usercredentials:
+ - username: vnfm
+ password: $2a$10$Fh9ffgPw2vnmsghsRD3ZauBL1aKXebigbq3BB1RPWtE62UDILsjke
+ role: BPEL-Client
+ main:
+ allow-bean-definition-overriding: true
server:
- port: 9093
- tomcat:
- max-threads: 50
- ssl:
- key-alias: so@so.onap.org
- key--store-password: '7Em3&j4.19xYiMelhD5?xbQ.'
- key-store: classpath:so-vnfm-simulator.p12
- key-store-type: PKCS12
-
+ port: 9093
+ tomcat:
+ max-threads: 50
+ ssl:
+ key-alias: so@so.onap.org
+ key--store-password: 7Em3&j4.19xYiMelhD5?xbQ.
+ key-store: classpath:so-vnfm-simulator.p12
+ key-store-type: PKCS12
+http:
+ client:
+ ssl:
+ trust-store: classpath:so-vnfm-adapter.p12
+ trust-store-password: ywsqCy:EEo#j}HJHM7z^Rk[L
+endpoint:
+ callbackUri: https://so-vnfm-simulator.onap:9093/vnfpkgm/v1/notification
+vnfm-adapter:
+ auth:
+ name: vnfm
+ password: password1$
vnfds:
- vnfdlist:
- - vnfdid: 1
- vnfclist:
- - vnfcid: VNFC1
- resourceTemplateId: vnfd1_vnfc1
- vduId: vnfd1_vduForVnfc1
- type: COMPUTE
- - vnfcid: VNFC2
- resourceTemplateId: vnfd1_vnfc2
- vduId: vnfd1_vduForVnfc2
- type: COMPUTE
- - vnfdid: 2
- vnfclist:
- - vnfcid: VNFC3
- resourceTemplateId: vnfd2_vnfc3
- vduId: vnfd2_vduForVnfc3
- type: COMPUTE
- - vnfcid: VNFC4
- resourceTemplateId: vnfd2_vnfc4
- vduId: vnfd2_vduForVnfc4
- type: COMPUTE
+ vnfdlist:
+ - vnfdid: 1
+ vnfclist:
+ - vnfcid: VNFC1
+ resourceTemplateId: vnfd1_vnfc1
+ vduId: vnfd1_vduForVnfc1
+ type: COMPUTE
+ - vnfcid: VNFC2
+ resourceTemplateId: vnfd1_vnfc2
+ vduId: vnfd1_vduForVnfc2
+ type: COMPUTE
+ - vnfdid: 2
+ vnfclist:
+ - vnfcid: VNFC3
+ resourceTemplateId: vnfd2_vnfc3
+ vduId: vnfd2_vduForVnfc3
+ type: COMPUTE
+ - vnfcid: VNFC4
+ resourceTemplateId: vnfd2_vnfc4
+ vduId: vnfd2_vduForVnfc4
+ type: COMPUTE
diff --git a/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/resources/so-vnfm-adapter.jks b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/resources/so-vnfm-adapter.jks
new file mode 100644
index 0000000..ac3113f
--- /dev/null
+++ b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/resources/so-vnfm-adapter.jks
Binary files differ
diff --git a/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/resources/so-vnfm-adapter.p12 b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/resources/so-vnfm-adapter.p12
new file mode 100644
index 0000000..ae4fddc
--- /dev/null
+++ b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/main/resources/so-vnfm-adapter.p12
Binary files differ
diff --git a/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/test/java/org/onap/so/svnfm/simulator/controllers/TestSubscriptionNotificationController.java b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/test/java/org/onap/so/svnfm/simulator/controllers/TestSubscriptionNotificationController.java
new file mode 100644
index 0000000..743e2c0
--- /dev/null
+++ b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/test/java/org/onap/so/svnfm/simulator/controllers/TestSubscriptionNotificationController.java
@@ -0,0 +1,194 @@
+/*-
+ * ============LICENSE_START=======================================================
+ * Copyright (C) 2020 Nordix Foundation.
+ * ================================================================================
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ *
+ * SPDX-License-Identifier: Apache-2.0
+ * ============LICENSE_END=========================================================
+ */
+
+package org.onap.so.svnfm.simulator.controllers;
+
+import com.google.gson.Gson;
+import com.google.gson.GsonBuilder;
+import org.junit.After;
+import org.junit.Before;
+import org.junit.Test;
+import org.junit.runner.RunWith;
+import org.onap.so.adapters.vnfmadapter.extclients.vnfm.packagemanagement.model.InlineResponse201;
+import org.onap.so.adapters.vnfmadapter.extclients.vnfm.packagemanagement.model.PkgmSubscriptionRequest;
+import org.onap.so.adapters.vnfmadapter.extclients.vnfm.packagemanagement.model.SubscriptionsFilter1;
+import org.onap.so.adapters.vnfmadapter.extclients.vnfm.packagemanagement.notification.model.VnfPackageOnboardingNotification;
+import org.onap.so.svnfm.simulator.config.SvnfmApplication;
+import org.slf4j.Logger;
+import org.springframework.beans.factory.annotation.Autowired;
+import org.springframework.beans.factory.annotation.Qualifier;
+import org.springframework.boot.test.context.SpringBootTest;
+import org.springframework.boot.test.web.client.TestRestTemplate;
+import org.springframework.boot.web.server.LocalServerPort;
+import org.springframework.http.HttpEntity;
+import org.springframework.http.HttpHeaders;
+import org.springframework.http.HttpMethod;
+import org.springframework.http.HttpStatus;
+import org.springframework.http.ResponseEntity;
+import org.springframework.test.context.ActiveProfiles;
+import org.springframework.test.context.junit4.SpringRunner;
+import org.springframework.test.web.client.MockRestServiceServer;
+import org.springframework.web.client.RestTemplate;
+import java.time.LocalDateTime;
+
+import static org.junit.Assert.assertEquals;
+import static org.onap.so.adapters.vnfmadapter.extclients.vnfm.packagemanagement.model.SubscriptionsFilter.NotificationTypesEnum.VNFPACKAGECHANGENOTIFICATION;
+import static org.onap.so.adapters.vnfmadapter.extclients.vnfm.packagemanagement.model.SubscriptionsFilter.NotificationTypesEnum.VNFPACKAGEONBOARDINGNOTIFICATION;
+import static org.onap.so.svnfm.simulator.config.SslBasedRestTemplateConfiguration.SSL_BASED_CONFIGURABLE_REST_TEMPLATE;
+import static org.onap.so.svnfm.simulator.constants.Constant.NOTIFICATION_ENDPOINT;
+import static org.onap.so.svnfm.simulator.constants.Constant.PACKAGE_MANAGEMENT_BASE_URL;
+import static org.onap.so.svnfm.simulator.constants.Constant.SUBSCRIPTION_ENDPOINT;
+import static org.onap.so.svnfm.simulator.constants.Constant.VNFM_ADAPTER_SUBSCRIPTION_ENDPOINT;
+import static org.onap.so.svnfm.simulator.utils.TestUtils.getBaseUrl;
+import static org.onap.so.svnfm.simulator.utils.TestUtils.getBasicAuth;
+import static org.onap.so.svnfm.simulator.utils.TestUtils.getHttpHeaders;
+import static org.onap.so.svnfm.simulator.utils.TestUtils.getNotification;
+import static org.onap.so.svnfm.simulator.utils.TestUtils.getSubscriptionRequest;
+import static org.slf4j.LoggerFactory.getLogger;
+import static org.springframework.http.MediaType.APPLICATION_JSON;
+import static org.springframework.test.web.client.match.MockRestRequestMatchers.content;
+import static org.springframework.test.web.client.match.MockRestRequestMatchers.method;
+import static org.springframework.test.web.client.match.MockRestRequestMatchers.requestTo;
+import static org.springframework.test.web.client.response.MockRestResponseCreators.withSuccess;
+
+/**
+ * @author Andrew Lamb (andrew.a.lamb@est.tech)
+ */
+@RunWith(SpringRunner.class)
+@SpringBootTest(classes = SvnfmApplication.class, webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
+@ActiveProfiles("test")
+public class TestSubscriptionNotificationController {
+
+ private static final Logger LOGGER = getLogger(TestSubscriptionNotificationController.class);
+
+ @LocalServerPort
+ private int port;
+
+ @Autowired @Qualifier(SSL_BASED_CONFIGURABLE_REST_TEMPLATE)
+ private RestTemplate restTemplate;
+ private MockRestServiceServer mockRestServiceServer;
+
+ @Autowired
+ private TestRestTemplate testRestTemplate;
+
+ private Gson gson;
+ private String vnfmSimulatorCallbackUrl;
+
+ @Before
+ public void setup() {
+ mockRestServiceServer = MockRestServiceServer.bindTo(restTemplate).build();
+ gson = new GsonBuilder().create();
+ vnfmSimulatorCallbackUrl = getBaseUrl(port) + PACKAGE_MANAGEMENT_BASE_URL + NOTIFICATION_ENDPOINT;
+ }
+
+ @After
+ public void teardown() {
+ mockRestServiceServer.reset();
+ }
+
+ @Test
+ public void testGetFromEndpoint_Success() {
+ final ResponseEntity<?> responseEntity = checkGetFromTestEndpoint();
+ assertEquals(HttpStatus.NO_CONTENT, responseEntity.getStatusCode());
+ }
+
+ @Test
+ public void testPostOnboardingSubscriptionRequest_Success() throws Exception {
+ final PkgmSubscriptionRequest pkgmSubscriptionRequest =
+ gson.fromJson(getSubscriptionRequest(VNFPACKAGEONBOARDINGNOTIFICATION), PkgmSubscriptionRequest.class);
+ pkgmSubscriptionRequest.setCallbackUri(vnfmSimulatorCallbackUrl);
+ final InlineResponse201 inlineResponse =
+ new InlineResponse201().id("subscriptionId").filter(new SubscriptionsFilter1())
+ .callbackUri("callbackUri");
+
+ mockRestServiceServer.expect(requestTo(VNFM_ADAPTER_SUBSCRIPTION_ENDPOINT)).andExpect(method(HttpMethod.POST))
+ .andExpect(content().json(gson.toJson(pkgmSubscriptionRequest)))
+ .andRespond(withSuccess(gson.toJson(inlineResponse), APPLICATION_JSON));
+
+ final ResponseEntity<?> responseEntity = postSubscriptionRequest(pkgmSubscriptionRequest);
+ final InlineResponse201 responseEntityBody = (InlineResponse201) responseEntity.getBody();
+ assertEquals(HttpStatus.OK, responseEntity.getStatusCode());
+ assertEquals(inlineResponse, responseEntityBody);
+ }
+
+ @Test
+ public void testPostChangeSubscriptionRequest_Success() throws Exception {
+ final PkgmSubscriptionRequest pkgmSubscriptionRequest =
+ gson.fromJson(getSubscriptionRequest(VNFPACKAGECHANGENOTIFICATION), PkgmSubscriptionRequest.class);
+ pkgmSubscriptionRequest.setCallbackUri(vnfmSimulatorCallbackUrl);
+ final InlineResponse201 inlineResponse =
+ new InlineResponse201().id("subscriptionId").filter(new SubscriptionsFilter1())
+ .callbackUri("callbackUri");
+
+ mockRestServiceServer.expect(requestTo(VNFM_ADAPTER_SUBSCRIPTION_ENDPOINT)).andExpect(method(HttpMethod.POST))
+ .andExpect(content().json(gson.toJson(pkgmSubscriptionRequest)))
+ .andRespond(withSuccess(gson.toJson(inlineResponse), APPLICATION_JSON));
+
+ final ResponseEntity<?> responseEntity = postSubscriptionRequest(pkgmSubscriptionRequest);
+ final InlineResponse201 responseEntityBody = (InlineResponse201) responseEntity.getBody();
+ assertEquals(HttpStatus.OK, responseEntity.getStatusCode());
+ assertEquals(inlineResponse, responseEntityBody);
+ }
+
+ @Test
+ public void testNotificationEndpoint_Success() throws Exception {
+ final VnfPackageOnboardingNotification vnfPackageOnboardingNotification =
+ gson.fromJson(getNotification(VNFPACKAGEONBOARDINGNOTIFICATION),
+ VnfPackageOnboardingNotification.class);
+ final LocalDateTime timestamp = LocalDateTime.of(2020, 1, 1, 1, 1, 1, 1);
+ vnfPackageOnboardingNotification.setTimeStamp(timestamp);
+ final ResponseEntity<?> responseEntity = postNotification(vnfPackageOnboardingNotification);
+ assertEquals(HttpStatus.NO_CONTENT, responseEntity.getStatusCode());
+ }
+
+ private ResponseEntity<Void> checkGetFromTestEndpoint() {
+ LOGGER.info("checkGetFromTestEndpoint() method...");
+ final String vnfmSimulatorTestEndpoint = getBaseUrl(port) + PACKAGE_MANAGEMENT_BASE_URL;
+ final String authHeader = getBasicAuth("vnfm", "password1$");
+ final HttpHeaders headers = getHttpHeaders(authHeader);
+ final HttpEntity<?> request = new HttpEntity<>(headers);
+
+ LOGGER.info("sending request {} to: {}", request, vnfmSimulatorTestEndpoint);
+ return testRestTemplate.exchange(vnfmSimulatorTestEndpoint, HttpMethod.GET, request, Void.class);
+ }
+
+ private ResponseEntity<?> postSubscriptionRequest(final PkgmSubscriptionRequest subscriptionRequest) {
+ LOGGER.info("postSubscriptionRequest() method...");
+ final String vnfmSimulatorSubscribeEndpoint =
+ getBaseUrl(port) + PACKAGE_MANAGEMENT_BASE_URL + SUBSCRIPTION_ENDPOINT;
+ final String authHeader = getBasicAuth("vnfm", "password1$");
+ final HttpHeaders headers = getHttpHeaders(authHeader);
+ final HttpEntity<?> request = new HttpEntity<>(subscriptionRequest, headers);
+
+ LOGGER.info("sending request {} to: {}", request, vnfmSimulatorSubscribeEndpoint);
+ return testRestTemplate
+ .exchange(vnfmSimulatorSubscribeEndpoint, HttpMethod.POST, request, InlineResponse201.class);
+ }
+
+ private ResponseEntity<?> postNotification(final Object notification) {
+ LOGGER.info("postNotification method...");
+ final String authHeader = getBasicAuth("vnfm", "password1$");
+ final HttpHeaders headers = getHttpHeaders(authHeader);
+ final HttpEntity<?> request = new HttpEntity<>(notification, headers);
+
+ LOGGER.info("sending request {} to: {}", request, vnfmSimulatorCallbackUrl);
+ return testRestTemplate.exchange(vnfmSimulatorCallbackUrl, HttpMethod.POST, request, Void.class);
+ }
+}
diff --git a/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/test/java/org/onap/so/svnfm/simulator/utils/TestUtils.java b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/test/java/org/onap/so/svnfm/simulator/utils/TestUtils.java
new file mode 100644
index 0000000..e03f945
--- /dev/null
+++ b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/test/java/org/onap/so/svnfm/simulator/utils/TestUtils.java
@@ -0,0 +1,87 @@
+/*-
+ * ============LICENSE_START=======================================================
+ * Copyright (C) 2020 Nordix Foundation.
+ * ================================================================================
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ *
+ * SPDX-License-Identifier: Apache-2.0
+ * ============LICENSE_END=========================================================
+ */
+package org.onap.so.svnfm.simulator.utils;
+
+import org.onap.so.adapters.vnfmadapter.extclients.vnfm.packagemanagement.model.SubscriptionsFilter;
+import org.springframework.core.io.ClassPathResource;
+import org.springframework.http.HttpHeaders;
+import javax.ws.rs.core.MediaType;
+import java.io.File;
+import java.io.IOException;
+import java.nio.charset.StandardCharsets;
+import java.nio.file.Files;
+import org.apache.commons.codec.binary.Base64;
+
+/**
+ * @author Andrew Lamb (andrew.a.lamb@est.tech)
+ *
+ */
+public class TestUtils {
+
+ public static String getBasicAuth(final String username, final String password) {
+ final String auth = username + ":" + password;
+ return "Basic " + new String(Base64.encodeBase64(auth.getBytes(StandardCharsets.ISO_8859_1)));
+ }
+
+ public static HttpHeaders getHttpHeaders(final String authHeader) {
+ final HttpHeaders headers = new HttpHeaders();
+ headers.add(HttpHeaders.AUTHORIZATION, authHeader);
+ headers.add(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_JSON);
+ headers.add(HttpHeaders.ACCEPT, MediaType.APPLICATION_JSON);
+ return headers;
+ }
+
+ public static File getFile(final String file) throws IOException {
+ return new ClassPathResource(file).getFile();
+ }
+
+ public static String getJsonString(final String file) throws IOException {
+ return new String(Files.readAllBytes(getFile(file).toPath()));
+ }
+
+ public static String getBaseUrl(final int port) {
+ return "http://localhost:" + port;
+ }
+
+ public static String getSubscriptionRequest(final SubscriptionsFilter.NotificationTypesEnum notificationType) throws Exception {
+ switch (notificationType) {
+ case VNFPACKAGECHANGENOTIFICATION:
+ return getJsonString("test-data/pkg-subscription-request-change.json");
+ case VNFPACKAGEONBOARDINGNOTIFICATION:
+ return getJsonString("test-data/pkg-subscription-request-onboarding.json");
+ default:
+ return null;
+ }
+ }
+
+ public static String getNotification(final SubscriptionsFilter.NotificationTypesEnum notificationType) throws Exception {
+ switch (notificationType) {
+ case VNFPACKAGECHANGENOTIFICATION:
+ return getJsonString("test-data/vnf-package-change-notification.json");
+ case VNFPACKAGEONBOARDINGNOTIFICATION:
+ return getJsonString("test-data/vnf-package-onboarding-notification.json");
+ default:
+ return null;
+ }
+ }
+
+ private TestUtils() {}
+
+}
diff --git a/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/test/resources/application.yaml b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/test/resources/application.yaml
new file mode 100644
index 0000000..3a2268c
--- /dev/null
+++ b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/test/resources/application.yaml
@@ -0,0 +1,64 @@
+# Copyright © 2019 Nordix Foundation
+#
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+spring:
+ h2:
+ console: null
+ enabled: true
+ path: console
+ datasource:
+ url: jdbc:h2:mem:testdb;DB_CLOSE_ON_EXIT=FALSE
+ username: admin
+ password: admin
+ http:
+ converters:
+ preferred-json-mapper: gson
+ security:
+ usercredentials:
+ - username: vnfm
+ password: $2a$10$Fh9ffgPw2vnmsghsRD3ZauBL1aKXebigbq3BB1RPWtE62UDILsjke
+ role: BPEL-Client
+ main:
+ allow-bean-definition-overriding: true
+server:
+ port: 9093
+ tomcat:
+ max-threads: 50
+endpoint:
+ callbackUri: https://so-vnfm-simulator.onap:9093/vnfpkgm/v1/notification
+vnfm-adapter:
+ auth:
+ name: vnfm
+ password: password1$
+vnfds:
+ vnfdlist:
+ - vnfdid: 1
+ vnfclist:
+ - vnfcid: VNFC1
+ resourceTemplateId: vnfd1_vnfc1
+ vduId: vnfd1_vduForVnfc1
+ type: COMPUTE
+ - vnfcid: VNFC2
+ resourceTemplateId: vnfd1_vnfc2
+ vduId: vnfd1_vduForVnfc2
+ type: COMPUTE
+ - vnfdid: 2
+ vnfclist:
+ - vnfcid: VNFC3
+ resourceTemplateId: vnfd2_vnfc3
+ vduId: vnfd2_vduForVnfc3
+ type: COMPUTE
+ - vnfcid: VNFC4
+ resourceTemplateId: vnfd2_vnfc4
+ vduId: vnfd2_vduForVnfc4
+ type: COMPUTE
diff --git a/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/test/resources/test-data/pkg-subscription-request-change.json b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/test/resources/test-data/pkg-subscription-request-change.json
new file mode 100644
index 0000000..862ed59
--- /dev/null
+++ b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/test/resources/test-data/pkg-subscription-request-change.json
@@ -0,0 +1,43 @@
+{
+ "filter": {
+ "notificationTypes": [
+ "VnfPackageChangeNotification"
+ ],
+ "vnfProductsFromProviders": [
+ {
+ "vnfProvider": "Ericsson",
+ "vnfProducts": [
+ {
+ "vnfProductName": "VnfProducts",
+ "versions": [
+ {
+ "vnfSoftwareVersion": "vnfSoftwareVersion",
+ "vnfdVersions": [
+ "version1"
+ ]
+ }
+ ]
+ }
+ ]
+ }
+ ],
+ "vnfdId": [
+ "VNFDID"
+ ],
+ "vnfPkgId": [
+ "VNFPKGID"
+ ],
+ "operationalState": ["ENABLED"],
+ "usageState": []
+ },
+ "callbackUri": "https://so-vnfm-simulator.onap:9093/vnfpkgm/v1/notification",
+ "authentication": {
+ "authType": [
+ "BASIC"
+ ],
+ "paramsBasic": {
+ "userName": "vnfm",
+ "password": "password1$"
+ }
+ }
+}
diff --git a/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/test/resources/test-data/pkg-subscription-request-onboarding.json b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/test/resources/test-data/pkg-subscription-request-onboarding.json
new file mode 100644
index 0000000..3aa192e
--- /dev/null
+++ b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/test/resources/test-data/pkg-subscription-request-onboarding.json
@@ -0,0 +1,43 @@
+{
+ "filter": {
+ "notificationTypes": [
+ "VnfPackageOnboardingNotification"
+ ],
+ "vnfProductsFromProviders": [
+ {
+ "vnfProvider": "Ericsson",
+ "vnfProducts": [
+ {
+ "vnfProductName": "VnfProducts",
+ "versions": [
+ {
+ "vnfSoftwareVersion": "vnfSoftwareVersion",
+ "vnfdVersions": [
+ "version1"
+ ]
+ }
+ ]
+ }
+ ]
+ }
+ ],
+ "vnfdId": [
+ "VNFDID"
+ ],
+ "vnfPkgId": [
+ "VNFPKGID"
+ ],
+ "operationalState": ["ENABLED"],
+ "usageState": []
+ },
+ "callbackUri": "https://so-vnfm-simulator.onap:9093/vnfpkgm/v1/notification",
+ "authentication": {
+ "authType": [
+ "BASIC"
+ ],
+ "paramsBasic": {
+ "userName": "vnfm",
+ "password": "password1$"
+ }
+ }
+}
diff --git a/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/test/resources/test-data/vnf-package-change-notification.json b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/test/resources/test-data/vnf-package-change-notification.json
new file mode 100644
index 0000000..0022ecf
--- /dev/null
+++ b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/test/resources/test-data/vnf-package-change-notification.json
@@ -0,0 +1,17 @@
+{
+ "id": "string",
+ "notificationType": "VnfPackageChangeNotification",
+ "subscriptionId": "string",
+ "vnfPkgId": "string",
+ "vnfdId": "string",
+ "changeType": "OP_STATE_CHANGE",
+ "operationalState": ["ENABLED"],
+ "_links": {
+ "vnfPackage": {
+ "href": "string"
+ },
+ "subscription": {
+ "href": "string"
+ }
+ }
+}
diff --git a/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/test/resources/test-data/vnf-package-onboarding-notification.json b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/test/resources/test-data/vnf-package-onboarding-notification.json
new file mode 100644
index 0000000..40b565b
--- /dev/null
+++ b/plans/so/integration-etsi-testing/so-simulators/vnfm-simulator/vnfm-service/src/test/resources/test-data/vnf-package-onboarding-notification.json
@@ -0,0 +1,15 @@
+{
+ "id": "string",
+ "notificationType": "VnfPackageOnboardingNotification",
+ "subscriptionId": "string",
+ "vnfPkgId": "string",
+ "vnfdId": "string",
+ "_links": {
+ "vnfPackage": {
+ "href": "string"
+ },
+ "subscription": {
+ "href": "string"
+ }
+ }
+}