diff options
Diffstat (limited to 'adapters')
7 files changed, 7701 insertions, 2 deletions
diff --git a/adapters/mso-vnfm-adapter/mso-vnfm-adapter-ext-clients/pom.xml b/adapters/mso-vnfm-adapter/mso-vnfm-adapter-ext-clients/pom.xml index 91478e1f8e..784c39c906 100644 --- a/adapters/mso-vnfm-adapter/mso-vnfm-adapter-ext-clients/pom.xml +++ b/adapters/mso-vnfm-adapter/mso-vnfm-adapter-ext-clients/pom.xml @@ -75,8 +75,7 @@ <goal>generate</goal> </goals> <configuration> - <inputSpec>${basedir}/src/main/resources/SOL003-VNFLifecycleOperationGranting-API.json - </inputSpec> + <inputSpec>${basedir}/src/main/resources/SOL003-VNFLifecycleOperationGranting-API.json</inputSpec> <language>java</language> <library>okhttp-gson</library> <output>${project.build.directory}/generated-sources/sol003-vnf-grant</output> @@ -91,6 +90,26 @@ </configOptions> </configuration> </execution> + <execution> + <id>sol003-vnf-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> diff --git a/adapters/mso-vnfm-adapter/mso-vnfm-adapter-ext-clients/src/main/resources/SOL003-VNFPackageManagement-API.json b/adapters/mso-vnfm-adapter/mso-vnfm-adapter-ext-clients/src/main/resources/SOL003-VNFPackageManagement-API.json new file mode 100644 index 0000000000..1f4a8ac306 --- /dev/null +++ b/adapters/mso-vnfm-adapter/mso-vnfm-adapter-ext-clients/src/main/resources/SOL003-VNFPackageManagement-API.json @@ -0,0 +1,7311 @@ +{ + "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" + }, + "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" + }, + "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": "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" + }, + "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": "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" + } + } + } + } + } + } + } + } + }, + "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/adapters/mso-vnfm-adapter/mso-vnfm-etsi-adapter/src/main/java/org/onap/so/adapters/vnfmadapter/Constants.java b/adapters/mso-vnfm-adapter/mso-vnfm-etsi-adapter/src/main/java/org/onap/so/adapters/vnfmadapter/Constants.java index 1695b39c85..40be4411c8 100644 --- a/adapters/mso-vnfm-adapter/mso-vnfm-etsi-adapter/src/main/java/org/onap/so/adapters/vnfmadapter/Constants.java +++ b/adapters/mso-vnfm-adapter/mso-vnfm-etsi-adapter/src/main/java/org/onap/so/adapters/vnfmadapter/Constants.java @@ -28,6 +28,8 @@ public class Constants { public static final String SERVICE_NAME = "vnfm-adapter"; public static final String SERVICE_VERSION = "v1"; public static final String BASE_URL = "/so/" + SERVICE_NAME + "/" + SERVICE_VERSION; + public static final String PACKAGE_MANAGEMENT_BASE_URL = BASE_URL + "/vnfpkgm/v1"; + public static final String APPLICATION_ZIP = "application/zip"; public static final String OPERATION_NOTIFICATION_ENDPOINT = "/lcn/VnfLcmOperationOccurrenceNotification"; private Constants() {} diff --git a/adapters/mso-vnfm-adapter/mso-vnfm-etsi-adapter/src/main/java/org/onap/so/adapters/vnfmadapter/rest/Sol003PackageManagementController.java b/adapters/mso-vnfm-adapter/mso-vnfm-etsi-adapter/src/main/java/org/onap/so/adapters/vnfmadapter/rest/Sol003PackageManagementController.java new file mode 100644 index 0000000000..1da1159be0 --- /dev/null +++ b/adapters/mso-vnfm-adapter/mso-vnfm-etsi-adapter/src/main/java/org/onap/so/adapters/vnfmadapter/rest/Sol003PackageManagementController.java @@ -0,0 +1,118 @@ +/*- + * ============LICENSE_START======================================================= + * Copyright (C) 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. + * + * SPDX-License-Identifier: Apache-2.0 + * ============LICENSE_END========================================================= + */ + +package org.onap.so.adapters.vnfmadapter.rest; + +import static org.onap.so.adapters.vnfmadapter.Constants.APPLICATION_ZIP; +import static org.onap.so.adapters.vnfmadapter.Constants.PACKAGE_MANAGEMENT_BASE_URL; +import static org.slf4j.LoggerFactory.getLogger; +import java.util.List; +import javax.ws.rs.core.MediaType; +import org.onap.so.adapters.vnfmadapter.extclients.vnfm.packagemanagement.model.InlineResponse2001; +import org.slf4j.Logger; +import org.springframework.http.HttpStatus; +import org.springframework.http.ResponseEntity; +import org.springframework.stereotype.Controller; +import org.springframework.web.bind.annotation.GetMapping; +import org.springframework.web.bind.annotation.PathVariable; +import org.springframework.web.bind.annotation.RequestMapping; + +/** + * Controller for handling the VNF Package Management. For further information please read: + * https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/02.05.01_60/gs_nfv-sol003v020501p.pdf Use the section number + * above each endpoint to find the corresponding section in the above document. + * + * @author gareth.roper@est.tech + */ +@Controller +@RequestMapping(value = PACKAGE_MANAGEMENT_BASE_URL, consumes = {MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML}) +public class Sol003PackageManagementController { + + private static final String LOG_REQUEST_RECEIVED = "VNF Package Management Controller: {} {} {} {} {}"; + private static final Logger logger = getLogger(Sol003PackageManagementController.class); + + /** + * GET VNF packages information. Direction: VNFM -> VNFM-Adapter. Will return zero or more VNF package + * representations that match the attribute filter. These representations will be in a list. Section Number: 10.4.2 + * + * @return A List of all VNF packages. Object: List<InlineResponse2001> Response Code: 200 OK + */ + + @GetMapping(value = "/vnf_packages", produces = {MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML}) + public ResponseEntity<List<InlineResponse2001>> getVnfPackages() { + logger.info(LOG_REQUEST_RECEIVED, "getVnfPackages."); + return new ResponseEntity<>(HttpStatus.NOT_IMPLEMENTED); + } + + /** + * GET VNF package information. Direction: VNFM -> VNFM-Adapter. Will return a specific VNF package representation + * that match the attribute filter. Section Number: 10.4.3 + * + * @param vnfPkgId The ID of the VNF Package that you want to query. + * @return A VNF package based on vnfPkgId. Object: VnfPkgInfo Response Code: 200 OK + */ + @GetMapping(value = "/vnf_packages/{vnfPkgId}", produces = {MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML}) + public ResponseEntity<InlineResponse2001> getVnfPackage(@PathVariable("vnfPkgId") final String vnfPkgId) { + logger.info(LOG_REQUEST_RECEIVED, "getVnfPackage: ", vnfPkgId); + return new ResponseEntity<>(HttpStatus.NOT_IMPLEMENTED); + } + + /** + * GET VNFD, from VNF package. Direction: VNFM -> VNFM-Adapter. Will return a copy of the file representing the VNFD + * or a ZIP file that contains the file/multiple files representing the VNFD specified. Section Number: 10.4.4 + * + * @param vnfPkgId The ID of the VNF Package that you want to retrieve the VNFD from. + * @return The VNFD of a VNF Package as a single file or within a ZIP file. Object: byte[] Response Code: 200 OK + */ + @GetMapping(value = "/vnf_packages/{vnfPkgId}/vnfd", produces = {MediaType.TEXT_PLAIN, APPLICATION_ZIP}) + public ResponseEntity<byte[]> getVnfPackageVnfd(@PathVariable("vnfPkgId") final String vnfPkgId) { + logger.info(LOG_REQUEST_RECEIVED, "getVnfPackageVnfd: ", vnfPkgId); + return new ResponseEntity<>(HttpStatus.NOT_IMPLEMENTED); + } + + /** + * GET Package Content, from VNF Package. Direction: VNFM -> VNFM-Adapter. Will return a copy of the VNF package + * file that you specified. Section Number: 10.4.5 + * + * @param vnfPkgId The ID of the VNF Package that you want to retrieve the "package_content" from. + * @return The Package Content of a VNF Package. Object: byte[] Response Code: 200 OK + */ + @GetMapping(value = "/vnf_packages/{vnfPkgId}/package_content", produces = {APPLICATION_ZIP}) + public ResponseEntity<byte[]> getVnfPackageContent(@PathVariable("vnfPkgId") final String vnfPkgId) { + logger.info(LOG_REQUEST_RECEIVED, "getVnfPackageContent: ", vnfPkgId); + return new ResponseEntity<>(HttpStatus.NOT_IMPLEMENTED); + } + + /** + * GET Artifact, from VNF Package. Direction: VNFM -> VNFM-Adapter. Will return a the content of the artifact that + * you specified. Section Number: 10.4.6 + * + * @param vnfPkgId The ID of the VNF Package that you want to retrieve an artifact from. + * @param artifactPath The path of the artifact that you want to retrieve. + * @return An Artifact from a VNF Package. Object: byte[] Response Code: 200 OK + */ + @GetMapping(value = "/vnf_packages/{vnfPkgId}/artifacts/{artifactPath}", + produces = {MediaType.APPLICATION_OCTET_STREAM}) + public ResponseEntity<byte[]> getVnfPackageArtifact(@PathVariable("vnfPkgId") final String vnfPkgId, + @PathVariable("artifactPath") final String artifactPath) { + logger.info(LOG_REQUEST_RECEIVED, "getVnfPackageArtifact: vnfPkgId=", vnfPkgId, " artifactPath=", artifactPath); + return new ResponseEntity<>(HttpStatus.NOT_IMPLEMENTED); + } +} diff --git a/adapters/mso-vnfm-adapter/mso-vnfm-etsi-adapter/src/main/java/org/onap/so/adapters/vnfmadapter/rest/Sol003SubscriptionManagementController.java b/adapters/mso-vnfm-adapter/mso-vnfm-etsi-adapter/src/main/java/org/onap/so/adapters/vnfmadapter/rest/Sol003SubscriptionManagementController.java new file mode 100644 index 0000000000..6fac952aa8 --- /dev/null +++ b/adapters/mso-vnfm-adapter/mso-vnfm-etsi-adapter/src/main/java/org/onap/so/adapters/vnfmadapter/rest/Sol003SubscriptionManagementController.java @@ -0,0 +1,108 @@ +/*- + * ============LICENSE_START======================================================= + * Copyright (C) 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. + * + * SPDX-License-Identifier: Apache-2.0 + * ============LICENSE_END========================================================= + */ + +package org.onap.so.adapters.vnfmadapter.rest; + +import static org.onap.so.adapters.vnfmadapter.Constants.PACKAGE_MANAGEMENT_BASE_URL; +import static org.slf4j.LoggerFactory.getLogger; +import java.util.List; +import javax.ws.rs.core.MediaType; +import org.onap.so.adapters.vnfmadapter.extclients.vnfm.packagemanagement.model.InlineResponse2002; +import org.onap.so.adapters.vnfmadapter.extclients.vnfm.packagemanagement.model.PkgmSubscriptionRequest; +import org.slf4j.Logger; +import org.springframework.http.HttpStatus; +import org.springframework.http.ResponseEntity; +import org.springframework.stereotype.Controller; +import org.springframework.web.bind.annotation.DeleteMapping; +import org.springframework.web.bind.annotation.GetMapping; +import org.springframework.web.bind.annotation.PathVariable; +import org.springframework.web.bind.annotation.PostMapping; +import org.springframework.web.bind.annotation.RequestBody; +import org.springframework.web.bind.annotation.RequestMapping; + +/** + * Controller for handling the Subscription Management. For further information please read: + * https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/02.05.01_60/gs_nfv-sol003v020501p.pdf Use the section number + * above each endpoint to find the corresponding section in the above document. + * + * @author gareth.roper@est.tech + */ +@Controller +@RequestMapping(value = PACKAGE_MANAGEMENT_BASE_URL, produces = {MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML}, + consumes = {MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML}) +public class Sol003SubscriptionManagementController { + + private static final String LOG_REQUEST_RECEIVED = "Subscription Management Controller: {} {}"; + private static final Logger logger = getLogger(Sol003SubscriptionManagementController.class); + + /** + * POST Subscribe request. Direction: VNFM -> VNFM Adapter. Will send request and respond with the subscription that + * you subscribed to, if successful. Section Number: 10.4.7 + * + * @param pkgmSubscriptionRequest This includes the details of the subscription to be created. + * @return The subscription requested, if successful. Object: InlineRespone2002 Response Code: 201 Created Response + * Code: 303 Duplicate Subscription + */ + @PostMapping(value = "/subscriptions") + public ResponseEntity<InlineResponse2002> postSubscriptionRequest( + @RequestBody final PkgmSubscriptionRequest pkgmSubscriptionRequest) { + logger.info(LOG_REQUEST_RECEIVED, " postSubscriptionRequest: ", pkgmSubscriptionRequest); + return new ResponseEntity<>(HttpStatus.NOT_IMPLEMENTED); + } + + /** + * GET all subscriptions. Direction: VNFM -> VNFM Adapter. Will return a list of all subscriptions currently active. + * Section Number: 10.4.7 + * + * @return All of the current active subscriptions. Object: List<InlineResponse2002> Response Code: 200 OK + */ + @GetMapping(value = "/subscriptions") + public ResponseEntity<List<InlineResponse2002>> getSubscriptions() { + logger.info(LOG_REQUEST_RECEIVED, " getSubscriptions."); + return new ResponseEntity<>(HttpStatus.NOT_IMPLEMENTED); + } + + /** + * GET a specific subscription, by subscriptionId. Direction: VNFM -> VNFM Adapter. Section Number: 10.4.8 + * + * @param subscriptionId The ID of the subscription that you wish to retrieve. + * @return A subscription based on subscriptionId. Object: InlineResponse2002 Response Code: 200 OK + */ + @GetMapping(value = "/subscriptions/{subscriptionId}") + public ResponseEntity<InlineResponse2002> getSubscription( + @PathVariable("subscriptionId") final String subscriptionId) { + logger.info(LOG_REQUEST_RECEIVED, " Getting Subscription: ", subscriptionId); + return new ResponseEntity<>(HttpStatus.NOT_IMPLEMENTED); + } + + /** + * DELETE a specific subscription, by subscriptionId. Direction: VNFM -> VNFM Adapter. Section Number: 10.4.7 + * + * @param subscriptionId The ID of the subscription that you wish to delete. + * @return Empty response if successful. Object: Void Response Code: 204 No Content + */ + @DeleteMapping(value = "/subscriptions/{subscriptionId}") + public ResponseEntity<Void> deleteSubscription(@PathVariable("subscriptionId") final String subscriptionId) { + logger.info(LOG_REQUEST_RECEIVED, " Deleting Subscription: ", subscriptionId); + return new ResponseEntity<>(HttpStatus.NOT_IMPLEMENTED); + } + + +} diff --git a/adapters/mso-vnfm-adapter/mso-vnfm-etsi-adapter/src/test/java/org/onap/so/adapters/vnfmadapter/rest/Sol003PackageManagementControllerTest.java b/adapters/mso-vnfm-adapter/mso-vnfm-etsi-adapter/src/test/java/org/onap/so/adapters/vnfmadapter/rest/Sol003PackageManagementControllerTest.java new file mode 100644 index 0000000000..801c468018 --- /dev/null +++ b/adapters/mso-vnfm-adapter/mso-vnfm-etsi-adapter/src/test/java/org/onap/so/adapters/vnfmadapter/rest/Sol003PackageManagementControllerTest.java @@ -0,0 +1,74 @@ +package org.onap.so.adapters.vnfmadapter.rest; + + +import static org.junit.Assert.assertEquals; +import static org.onap.so.client.RestTemplateConfig.CONFIGURABLE_REST_TEMPLATE; +import java.net.URISyntaxException; +import java.util.List; +import org.junit.Before; +import org.junit.Test; +import org.junit.runner.RunWith; +import org.onap.so.adapters.vnfmadapter.VnfmAdapterApplication; +import org.onap.so.adapters.vnfmadapter.extclients.vnfm.packagemanagement.model.InlineResponse2001; +import org.springframework.beans.factory.annotation.Autowired; +import org.springframework.beans.factory.annotation.Qualifier; +import org.springframework.boot.test.context.SpringBootTest; +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; + +@RunWith(SpringRunner.class) +@SpringBootTest(classes = VnfmAdapterApplication.class, webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT) +@ActiveProfiles("test") +public class Sol003PackageManagementControllerTest { + + private static final String vnfPackageId = "myVnfPackageId"; + private static final String artifactPath = "myArtifactPath"; + + @Autowired + @Qualifier(CONFIGURABLE_REST_TEMPLATE) + private RestTemplate testRestTemplate; + private MockRestServiceServer mockRestServer; + + @Autowired + private Sol003PackageManagementController controller; + + @Before + public void setUp() throws Exception { + mockRestServer = MockRestServiceServer.bindTo(testRestTemplate).build(); + } + + @Test + public void getVnfPackages() throws URISyntaxException, InterruptedException { + final ResponseEntity<List<InlineResponse2001>> response = controller.getVnfPackages(); + assertEquals(HttpStatus.NOT_IMPLEMENTED, response.getStatusCode()); + } + + @Test + public void getVnfPackage() throws URISyntaxException, InterruptedException { + final ResponseEntity<InlineResponse2001> response = controller.getVnfPackage(vnfPackageId); + assertEquals(HttpStatus.NOT_IMPLEMENTED, response.getStatusCode()); + } + + @Test + public void getVnfPackageVnfd() throws URISyntaxException, InterruptedException { + final ResponseEntity<byte[]> response = controller.getVnfPackageVnfd(vnfPackageId); + assertEquals(HttpStatus.NOT_IMPLEMENTED, response.getStatusCode()); + } + + @Test + public void getVnfPackageContents() throws URISyntaxException, InterruptedException { + final ResponseEntity<byte[]> response = controller.getVnfPackageContent(vnfPackageId); + assertEquals(HttpStatus.NOT_IMPLEMENTED, response.getStatusCode()); + } + + @Test + public void getVnfPackageArtifact() throws URISyntaxException, InterruptedException { + final ResponseEntity<byte[]> response = controller.getVnfPackageArtifact(vnfPackageId, artifactPath); + assertEquals(HttpStatus.NOT_IMPLEMENTED, response.getStatusCode()); + } + +} diff --git a/adapters/mso-vnfm-adapter/mso-vnfm-etsi-adapter/src/test/java/org/onap/so/adapters/vnfmadapter/rest/Sol003SubscriptionManagementControllerTest.java b/adapters/mso-vnfm-adapter/mso-vnfm-etsi-adapter/src/test/java/org/onap/so/adapters/vnfmadapter/rest/Sol003SubscriptionManagementControllerTest.java new file mode 100644 index 0000000000..999dd02f0f --- /dev/null +++ b/adapters/mso-vnfm-adapter/mso-vnfm-etsi-adapter/src/test/java/org/onap/so/adapters/vnfmadapter/rest/Sol003SubscriptionManagementControllerTest.java @@ -0,0 +1,67 @@ +package org.onap.so.adapters.vnfmadapter.rest; + +import static org.junit.Assert.assertEquals; +import static org.onap.so.client.RestTemplateConfig.CONFIGURABLE_REST_TEMPLATE; +import java.net.URISyntaxException; +import java.util.List; +import org.junit.Before; +import org.junit.Test; +import org.junit.runner.RunWith; +import org.onap.so.adapters.vnfmadapter.VnfmAdapterApplication; +import org.onap.so.adapters.vnfmadapter.extclients.vnfm.packagemanagement.model.InlineResponse2002; +import org.onap.so.adapters.vnfmadapter.extclients.vnfm.packagemanagement.model.PkgmSubscriptionRequest; +import org.springframework.beans.factory.annotation.Autowired; +import org.springframework.beans.factory.annotation.Qualifier; +import org.springframework.boot.test.context.SpringBootTest; +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; + +@RunWith(SpringRunner.class) +@SpringBootTest(classes = VnfmAdapterApplication.class, webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT) +@ActiveProfiles("test") +public class Sol003SubscriptionManagementControllerTest { + + private static final String subscriptionId = "mySubscriptionId"; + + @Autowired + @Qualifier(CONFIGURABLE_REST_TEMPLATE) + private RestTemplate testRestTemplate; + private MockRestServiceServer mockRestServer; + + @Autowired + private Sol003SubscriptionManagementController controller; + + @Before + public void setUp() throws Exception { + mockRestServer = MockRestServiceServer.bindTo(testRestTemplate).build(); + } + + @Test + public void postSubscriptionRequest() throws URISyntaxException, InterruptedException { + final PkgmSubscriptionRequest pkgmSubscriptionRequest = new PkgmSubscriptionRequest(); + final ResponseEntity<InlineResponse2002> response = controller.postSubscriptionRequest(pkgmSubscriptionRequest); + assertEquals(HttpStatus.NOT_IMPLEMENTED, response.getStatusCode()); + } + + @Test + public void getSubscriptions() throws URISyntaxException, InterruptedException { + final ResponseEntity<List<InlineResponse2002>> response = controller.getSubscriptions(); + assertEquals(HttpStatus.NOT_IMPLEMENTED, response.getStatusCode()); + } + + @Test + public void deleteSubscription() throws URISyntaxException, InterruptedException { + final ResponseEntity<Void> response = controller.deleteSubscription(subscriptionId); + assertEquals(HttpStatus.NOT_IMPLEMENTED, response.getStatusCode()); + } + + @Test + public void getSubscription() throws URISyntaxException, InterruptedException { + final ResponseEntity<InlineResponse2002> response = controller.getSubscription(subscriptionId); + assertEquals(HttpStatus.NOT_IMPLEMENTED, response.getStatusCode()); + } +} |