From 7715169a104a3c0783799d9206880f8b85d34705 Mon Sep 17 00:00:00 2001
From: mxzhao <mengxuan.zhao@eglobalmark.com>
Date: Tue, 6 Nov 2018 11:39:18 +0100
Subject: [PATCH] SOL003-VirtualisedResourcesQuotaAvailableNotification-API
---
.../IndividualSubscription.robot | 62 +
.../NotificationEndpoint.robot | 41 +
...sourcesQuotaAvailableNotification-API.yaml | 2801 +++++++++++++++++
.../Subscriptions.robot | 96 +
.../vrQuotaAvailSubscriptionRequest .json | 3 +
.../variables.txt | 36 +
TrackingStatus.txt | 7 +-
7 files changed, 3044 insertions(+), 2 deletions(-)
create mode 100644 SOL003/VirtualisedResourcesQuotaAvailableNotification-API_egm/IndividualSubscription.robot
create mode 100644 SOL003/VirtualisedResourcesQuotaAvailableNotification-API_egm/NotificationEndpoint.robot
create mode 100644 SOL003/VirtualisedResourcesQuotaAvailableNotification-API_egm/SOL003-VirtualisedResourcesQuotaAvailableNotification-API.yaml
create mode 100644 SOL003/VirtualisedResourcesQuotaAvailableNotification-API_egm/Subscriptions.robot
create mode 100644 SOL003/VirtualisedResourcesQuotaAvailableNotification-API_egm/jsons/vrQuotaAvailSubscriptionRequest .json
create mode 100644 SOL003/VirtualisedResourcesQuotaAvailableNotification-API_egm/variables.txt
diff --git a/SOL003/VirtualisedResourcesQuotaAvailableNotification-API_egm/IndividualSubscription.robot b/SOL003/VirtualisedResourcesQuotaAvailableNotification-API_egm/IndividualSubscription.robot
new file mode 100644
index 00000000..34eae486
--- /dev/null
+++ b/SOL003/VirtualisedResourcesQuotaAvailableNotification-API_egm/IndividualSubscription.robot
@@ -0,0 +1,62 @@
+*** Settings ***
+Resource variables.txt
+Library REST http://${NFVO_HOST}:${NFVO_PORT}
+... spec=SOL003-VirtualisedResourcesQuotaAvailableNotification-API.yaml
+Documentation This resource represents an individual subscription. The client can use this resource to read and to terminate a
+... subscription to notifications related to the availability of the virtualised resources quotas.
+Suite setup Check resource existance
+
+*** Test Cases ***
+Post Individual Subscription - Method not implemented
+ log Trying to perform a POST. This method should not be implemented
+ Set Headers {"Accept":"${ACCEPT}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ Post ${apiRoot}/${apiName}/${apiVersion}/subscriptions/${subscriptionId}
+ Log Validate Status code
+ Output response
+ Integer response status 405
+
+Get Information about an individual subscription
+ log Trying to get information about an individual subscription
+ Set Headers {"Accept":"${ACCEPT}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ Get ${apiRoot}/${apiName}/${apiVersion}/subscriptions/${subscriptionId}
+ Log Validate Status code
+ Output response
+ Integer response status 200
+
+PUT an individual subscription - Method not implemented
+ log Trying to perform a PUT. This method should not be implemented
+ Set Headers {"Accept":"${ACCEPT}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ Put ${apiRoot}/${apiName}/${apiVersion}/subscriptions/${subscriptionId}
+ Log Validate Status code
+ Output response
+ Integer response status 405
+
+PATCH an individual subscription - Method not implemented
+ log Trying to perform a PATCH. This method should not be implemented
+ Set Headers {"Accept":"${ACCEPT}"}
+ Set Headers {"Content-Type": "${CONTENT_TYPE}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ Patch ${apiRoot}/${apiName}/${apiVersion}/subscriptions/${subscriptionId}
+ Log Validate Status code
+ Output response
+ Integer response status 405
+
+DELETE an individual subscription
+ log Try to delete an individual subscription
+ Set Headers {"Accept":"${ACCEPT}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ Delete ${apiRoot}/${apiName}/${apiVersion}/subscriptions/${subscriptionId}
+ Log Validate Status code
+ Output response
+ Integer response status 204
+
+*** Key words ***
+
+Check resource existance
+ Set Headers {"Accept":"${ACCEPT}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ Get ${apiRoot}/${apiName}/${apiVersion}/subscriptions/${subscriptionId}
+ Integer response status 200
\ No newline at end of file
diff --git a/SOL003/VirtualisedResourcesQuotaAvailableNotification-API_egm/NotificationEndpoint.robot b/SOL003/VirtualisedResourcesQuotaAvailableNotification-API_egm/NotificationEndpoint.robot
new file mode 100644
index 00000000..cd7e13c6
--- /dev/null
+++ b/SOL003/VirtualisedResourcesQuotaAvailableNotification-API_egm/NotificationEndpoint.robot
@@ -0,0 +1,41 @@
+*** Settings ***
+Resource variables.txt
+Library REST http://${VNFM_HOST}:${VNFM_PORT}
+... spec=SOL003-VirtualisedResourcesQuotaAvailableNotification-API.yaml
+
+*** Test Cases ***
+Deliver a notification - Operation Occurence
+ log The POST method delivers a notification from the server to the client.
+ Set Headers {"Content-Type": "${CONTENT_TYPE}"}
+ Post ${notification_ep} ${VrQuotaAvailNotification}
+ Log Validate Status code
+ Output response
+ Integer response status 204
+
+Test a notification end point
+ log The GET method allows the server to test the notification endpoint
+ Get ${notification_ep}
+ Log Validate Status code
+ Output response
+ Integer response status 204
+
+PUT notification - Method not implemented
+ log Trying to perform a PUT. This method should not be implemented
+ Put ${notification_ep}
+ Log Validate Status code
+ Output response
+ Integer response status 405
+
+PATCH subscriptions - Method not implemented
+ log Trying to perform a PATCH. This method should not be implemented
+ Patch ${notification_ep}
+ Log Validate Status code
+ Output response
+ Integer response status 405
+
+DELETE subscriptions - Method not implemented
+ log Trying to perform a DELETE. This method should not be implemented
+ Delete ${notification_ep}
+ Log Validate Status code
+ Output response
+ Integer response status 405
\ No newline at end of file
diff --git a/SOL003/VirtualisedResourcesQuotaAvailableNotification-API_egm/SOL003-VirtualisedResourcesQuotaAvailableNotification-API.yaml b/SOL003/VirtualisedResourcesQuotaAvailableNotification-API_egm/SOL003-VirtualisedResourcesQuotaAvailableNotification-API.yaml
new file mode 100644
index 00000000..1eb5dca4
--- /dev/null
+++ b/SOL003/VirtualisedResourcesQuotaAvailableNotification-API_egm/SOL003-VirtualisedResourcesQuotaAvailableNotification-API.yaml
@@ -0,0 +1,2801 @@
+swagger: '2.0'
+info:
+ version: 1.1.1
+ title: SOL003 - Virtualised Resources Quota Available Notification interface
+ description: >
+ SOL003 - Virtualised Resources Quota Available Notification interface
+
+
+ IMPORTANT: Please note that this file might be not aligned to the current
+ version of the ETSI Group Specification it refers to. In case of
+ discrepancies the published ETSI Group Specification takes precedence.
+
+
+ In clause 4.3.2 of ETSI GS NFV-SOL 003 v2.4.1, an attribute-based filtering
+ mechanism is defined. This mechanism is currently not included in the
+ corresponding OpenAPI design for this GS version. Changes to the
+ attribute-based filtering mechanism are being considered in v2.5.1 of this
+ GS for inclusion in the corresponding future ETSI NFV OpenAPI design.
+
+ Please report bugs to
+ https://forge.etsi.org/bugzilla/buglist.cgi?component=Nfv-Openapis&list_id=61&product=NFV&resolution=
+ license:
+ name: ETSI Forge copyright notice
+ url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt'
+externalDocs:
+ description: ETSI GS NFV-SOL 003 V2.4.1
+ url: >-
+ http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/02.04.01_60/gs_NFV-SOL003v020401p.pdf
+basePath: /vrqan/v1
+schemes:
+ - https
+consumes:
+ - application/json
+produces:
+ - application/json
+paths:
+ /subscriptions:
+ post:
+ description: >
+ Subscribe
+
+
+ The POST method creates a new subscription. Creation of two subscription
+ resources with the same callbackURI and the same filter can result in
+ performance degradation and will provide duplicates of notifications to
+ the 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).
+ parameters:
+ - name: Accept
+ description: >
+ Content-Types that are acceptable for the response. Reference: IETF
+ RFC 7231
+ in: header
+ required: true
+ type: string
+ - name: Authorization
+ description: |
+ The authorization token for the request. Reference: IETF RFC 7235
+ in: header
+ required: false
+ type: string
+ - name: Content-Type
+ description: >
+ The Content-Type header shall be set to
+ "application/merge-patch+json" according to IETF RFC 7396.
+ in: header
+ required: true
+ type: string
+ - name: VrQuotaAvailSubscriptionRequest
+ description: Details of the subscription to be created.
+ in: body
+ required: true
+ schema:
+ description: >
+ This type represents a subscription request related to
+ notifications related to the availability of the virtualised
+ resources quotas.
+ type: object
+ required:
+ - callbackUri
+ properties:
+ filter:
+ description: >
+ This type represents a subscription filter related to
+ notifications about the availability of the virtualised
+ resources quotas. At a particular nesting level in the filter
+ structure, the following applies: All attributes shall match
+ in order for the filter to match (logical "and" between
+ different filter attributes). If an attribute is an array, the
+ attribute shall match if at least one of the values in the
+ array matches (logical "or" between the values of one filter
+ attribute).
+ type: object
+ properties:
+ vimIds:
+ description: >
+ Match VIMs that were created the quota for a consumer of
+ the virtualised resources. This attribute shall only be
+ supported when VNF-related Resource Management in direct
+ mode is applicable.
+ type: array
+ items:
+ description: >
+ An identifier with the intention of being globally
+ unique.
+ type: string
+ resourceProviderIds:
+ description: >
+ Match the entities responsible for the management of the
+ virtualised resources that were allocated by the NFVO.
+ This attribute shall only be supported when VNF-related
+ Resource Management in indirect mode is applicable. The
+ identification scheme is outside the scope of the present
+ document.
+ type: array
+ items:
+ description: >
+ An identifier with the intention of being globally
+ unique.
+ type: string
+ resourceTypes:
+ description: |
+ Match particular resource types.
+ type: array
+ items:
+ type: string
+ enum:
+ - COMPUTE
+ - STORAGE
+ - NETWORK
+ resourceGroupIds:
+ description: >
+ Match the "infrastructure resource groups" that are
+ logical groupings of the virtualised resources assigned to
+ a tenant within an infrastructure Domain.
+ type: array
+ items:
+ description: >
+ An identifier maintained by the VIM or other resource
+ provider. It is expected to be unique within the VIM
+ instance.
+ type: string
+ callbackUri:
+ description: |
+ String formatted according to IETF RFC 3986.
+ 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.
+ * OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the
+ notification endpoint, use an OAuth 2.0 Bearer token, obtained
+ using the client credentials grant type.
+ * TLS_CERT: Every HTTP request to the notification
+ endpoint is sent
+ over a mutually authenticated TLS session, i.e. not only the
+ server is authenticated, but also the client is authenticated
+ during the TLS tunnel setup.
+ type: array
+ items:
+ type: string
+ enum:
+ - BASIC
+ - OAUTH2_CLIENT_CREDENTIALS
+ - TLS_CERT
+ paramsBasic:
+ description: >
+ Parameters for authentication/authorization using BASIC.
+ Shall be present if authType is "BASIC" and the contained
+ information has not been provisioned out of band. Shall be
+ absent otherwise.
+ type: object
+ properties:
+ userName:
+ description: >
+ Username to be used in HTTP Basic authentication.
+ Shall be present if it has not been provisioned out of
+ band.
+ type: string
+ password:
+ description: >
+ Password to be used in HTTP Basic authentication.
+ Shall be present if it has not been provisioned out of
+ band.
+ type: string
+ paramsOauth2ClientCredentials:
+ description: >
+ Parameters for authentication/authorization using
+ OAUTH2_CLIENT_CREDENTIALS. Shall be present if authType is
+ "OAUTH2_CLIENT_CREDENTIALS" and the contained information
+ has not been provisioned out of band. Shall be absent
+ otherwise.
+ type: object
+ properties:
+ clientId:
+ description: >
+ Client identifier to be used in the access token
+ request of the OAuth 2.0 client credentials grant
+ type. Shall be present if it has not been provisioned
+ out of band. The clientId and clientPassword passed in
+ a subscription shall not be the same as the clientId
+ and clientPassword that are used to obtain
+ authorization for API requests. Client credentials may
+ differ between subscriptions. The value of
+ clientPassword should be generated by a random
+ process.
+ type: string
+ clientPassword:
+ description: >
+ Client password to be used in the access token request
+ of the OAuth 2.0 client credentials grant type. Shall
+ be present if it has not been provisioned out of band.
+ The clientId and clientPassword passed in a
+ subscription shall not be the same as the clientId and
+ clientPassword that are used to obtain authorization
+ for API requests. Client credentials may differ
+ between subscriptions. The value of clientPassword
+ should be generated by a random process.
+ type: string
+ tokenEndpoint:
+ description: |
+ String formatted according to IETF RFC 3986.
+ type: string
+ responses:
+ '201':
+ description: >
+ Created
+
+ Representation of the created subscription resource. The HTTP
+ response shall include a "Location" HTTP header that points to the
+ created subscription resource.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the 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.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ description: >
+ This type represents a subscription related to notifications
+ related to the availability of the virtualised resources quotas.
+ type: object
+ required:
+ - id
+ - callbackUri
+ - _links
+ properties:
+ id:
+ description: |
+ An identifier with the intention of being globally unique.
+ type: string
+ filter:
+ description: >
+ This type represents a subscription filter related to
+ notifications about the availability of the virtualised
+ resources quotas. At a particular nesting level in the filter
+ structure, the following applies: All attributes shall match
+ in order for the filter to match (logical "and" between
+ different filter attributes). If an attribute is an array, the
+ attribute shall match if at least one of the values in the
+ array matches (logical "or" between the values of one filter
+ attribute).
+ type: object
+ properties:
+ vimIds:
+ description: >
+ Match VIMs that were created the quota for a consumer of
+ the virtualised resources. This attribute shall only be
+ supported when VNF-related Resource Management in direct
+ mode is applicable.
+ type: array
+ items:
+ description: >
+ An identifier with the intention of being globally
+ unique.
+ type: string
+ resourceProviderIds:
+ description: >
+ Match the entities responsible for the management of the
+ virtualised resources that were allocated by the NFVO.
+ This attribute shall only be supported when VNF-related
+ Resource Management in indirect mode is applicable. The
+ identification scheme is outside the scope of the present
+ document.
+ type: array
+ items:
+ description: >
+ An identifier with the intention of being globally
+ unique.
+ type: string
+ resourceTypes:
+ description: |
+ Match particular resource types.
+ type: array
+ items:
+ type: string
+ enum:
+ - COMPUTE
+ - STORAGE
+ - NETWORK
+ resourceGroupIds:
+ description: >
+ Match the "infrastructure resource groups" that are
+ logical groupings of the virtualised resources assigned to
+ a tenant within an infrastructure Domain.
+ type: array
+ items:
+ description: >
+ An identifier maintained by the VIM or other resource
+ provider. It is expected to be unique within the VIM
+ instance.
+ type: string
+ callbackUri:
+ description: |
+ String formatted according to IETF RFC 3986.
+ type: string
+ _links:
+ description: |
+ Links for this resource
+ type: object
+ required:
+ - self
+ properties:
+ self:
+ description: |
+ This type represents a link to a resource.
+ type: object
+ required:
+ - href
+ properties:
+ href:
+ description: |
+ URI of the referenced resource.
+ type: string
+ format: url
+ '303':
+ description: >
+ See Other
+
+ A subscription with the same callbackURI and the same filter already
+ exists and the policy of the VNFM is to not create redundant
+ subscriptions. The HTTP response shall include a "Location" HTTP
+ header that contains the resource URI of the existing subscription
+ resource. The response body shall be empty.
+ '400':
+ description: >
+ Bad Request
+
+ If the request is malformed or syntactically incorrect (e.g. if the
+ request URI contains incorrect query parameters or a syntactically
+ incorrect payload body), the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided, and
+ should include in the "detail" attribute more information about the
+ source of the problem.
+
+ ---
+
+ If the request contains a malformed access token, the API producer
+ should respond with this response. The details of the error shall be
+ returned in the WWW-Authenticate HTTP header, as defined in IETF RFC
+ 6750 and IETF RFC 7235. The ProblemDetails structure may be
+ provided.
+
+ ---
+
+ If there is an application error related to the client's input that
+ cannot be easily mapped to any other HTTP response code ("catch all
+ error"), the API producer shall respond with this response code.The
+ "ProblemDetails" structure shall be provided, and shall include in
+ the "detail" attribute more information about the source of the
+ problem.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '401':
+ description: >
+ Unauthorized
+
+ If the request contains no access token even though one is required,
+ or if the request contains an authorization token that is invalid
+ (e.g. expired or revoked), the API producer should respond with this
+ response. The details of the error shall be returned in the
+ WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF
+ RFC 7235. The ProblemDetails structure may be provided.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '403':
+ description: >
+ Forbidden
+
+ If the API consumer is not allowed to perform a particular request
+ to a particular resource, the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided. It
+ should include in the "detail" attribute information about the
+ source of the problem, and may indicate how to solve it.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '404':
+ description: >
+ Not Found
+
+ If 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.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '405':
+ description: >
+ Method Not Allowed
+
+ If a particular HTTP method is not supported for a particular
+ resource, the API producer shall respond with this response code.
+ The "ProblemDetails" structure may be omitted in that case.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '406':
+ description: >
+ Not Acceptable
+
+ If the "Accept" HTTP header does not contain at least one name of a
+ content type that is acceptable to the API producer, the API
+ producer shall respond with this response code. The "ProblemDetails"
+ structure may be omitted in that case.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '500':
+ description: >
+ Internal Server Error
+
+ If there is an application error not related to the client's input
+ that cannot be easily mapped to any other HTTP response code ("catch
+ all error"), the API producer shall respond withthis response code.
+ The "ProblemDetails" structure shall be provided, and shall include
+ in the "detail" attribute more information about the source of the
+ problem.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '503':
+ description: >
+ Service Unavailable
+
+ If the API producer encounters an internal overload situation of
+ itself or of a system it relies on, it should respond with this
+ response code, following the provisions in IETF RFC 7231 [13] for
+ the use of the "Retry-After" HTTP header and for the alternative to
+ refuse the connection. The "ProblemDetails" structure may be
+ omitted.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ get:
+ description: >
+ Query Subscription Information
+
+
+ The GET method allows the server to test the notification endpoint that
+ is provided by the client, e.g. during subscription.
+ parameters:
+ - name: Authorization
+ description: |
+ The authorization token for the request. Reference: IETF RFC 7235
+ in: header
+ required: false
+ type: string
+ responses:
+ '204':
+ description: >
+ No Content
+
+ The notification endpoint was tested successfully. The response body
+ shall be empty.
+ headers:
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ '400':
+ description: >
+ Bad Request
+
+ If the request is malformed or syntactically incorrect (e.g. if the
+ request URI contains incorrect query parameters or a syntactically
+ incorrect payload body), the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided, and
+ should include in the "detail" attribute more information about the
+ source of the problem.
+
+ ---
+
+ If the request contains a malformed access token, the API producer
+ should respond with this response. The details of the error shall be
+ returned in the WWW-Authenticate HTTP header, as defined in IETF RFC
+ 6750 and IETF RFC 7235. The ProblemDetails structure may be
+ provided.
+
+ ---
+
+ If there is an application error related to the client's input that
+ cannot be easily mapped to any other HTTP response code ("catch all
+ error"), the API producer shall respond with this response code.The
+ "ProblemDetails" structure shall be provided, and shall include in
+ the "detail" attribute more information about the source of the
+ problem.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '401':
+ description: >
+ Unauthorized
+
+ If the request contains no access token even though one is required,
+ or if the request contains an authorization token that is invalid
+ (e.g. expired or revoked), the API producer should respond with this
+ response. The details of the error shall be returned in the
+ WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF
+ RFC 7235. The ProblemDetails structure may be provided.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '403':
+ description: >
+ Forbidden
+
+ If the API consumer is not allowed to perform a particular request
+ to a particular resource, the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided. It
+ should include in the "detail" attribute information about the
+ source of the problem, and may indicate how to solve it.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '404':
+ description: >
+ Not Found
+
+ If 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.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '406':
+ description: >
+ Not Acceptable
+
+ If the "Accept" HTTP header does not contain at least one name of a
+ content type that is acceptable to the API producer, the API
+ producer shall respond with this response code. The "ProblemDetails"
+ structure may be omitted in that case.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '500':
+ description: >
+ Internal Server Error
+
+ If there is an application error not related to the client's input
+ that cannot be easily mapped to any other HTTP response code ("catch
+ all error"), the API producer shall respond withthis response code.
+ The "ProblemDetails" structure shall be provided, and shall include
+ in the "detail" attribute more information about the source of the
+ problem.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '503':
+ description: >
+ Service Unavailable
+
+ If the API producer encounters an internal overload situation of
+ itself or of a system it relies on, it should respond with this
+ response code, following the provisions in IETF RFC 7231 [13] for
+ the use of the "Retry-After" HTTP header and for the alternative to
+ refuse the connection. The "ProblemDetails" structure may be
+ omitted.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '/subscriptions/{subscriptionId}':
+ parameters:
+ - name: subscriptionId
+ description: >
+ Identifier of this subscription. This identifier can be retrieved from
+ the resource referenced by the "Location" HTTP header in the response
+ to a POST request creating a new subscription resource. It can also be
+ retrieved from the "id" attribute in the payload body of that
+ response.
+ in: path
+ type: string
+ required: true
+ get:
+ description: |
+ Query Subscription Information
+
+ The GET method reads an individual subscription.
+ parameters:
+ - name: Accept
+ description: >
+ Content-Types that are acceptable for the response. Reference: IETF
+ RFC 7231
+ in: header
+ required: true
+ type: string
+ - name: Authorization
+ description: |
+ The authorization token for the request. Reference: IETF RFC 7235
+ in: header
+ required: true
+ type: string
+ responses:
+ '200':
+ description: |
+ OK
+ Representation of the subscription resource.
+ headers:
+ Content-Type:
+ description: >
+ The MIME type of the body of the request. Reference: IETF RFC
+ 7231
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ This type represents a subscription related to notifications
+ related to the availability of the virtualised resources quotas.
+ type: object
+ required:
+ - id
+ - callbackUri
+ - _links
+ properties:
+ id:
+ description: |
+ An identifier with the intention of being globally unique.
+ type: string
+ filter:
+ description: >
+ This type represents a subscription filter related to
+ notifications about the availability of the virtualised
+ resources quotas. At a particular nesting level in the filter
+ structure, the following applies: All attributes shall match
+ in order for the filter to match (logical "and" between
+ different filter attributes). If an attribute is an array, the
+ attribute shall match if at least one of the values in the
+ array matches (logical "or" between the values of one filter
+ attribute).
+ type: object
+ properties:
+ vimIds:
+ description: >
+ Match VIMs that were created the quota for a consumer of
+ the virtualised resources. This attribute shall only be
+ supported when VNF-related Resource Management in direct
+ mode is applicable.
+ type: array
+ items:
+ description: >
+ An identifier with the intention of being globally
+ unique.
+ type: string
+ resourceProviderIds:
+ description: >
+ Match the entities responsible for the management of the
+ virtualised resources that were allocated by the NFVO.
+ This attribute shall only be supported when VNF-related
+ Resource Management in indirect mode is applicable. The
+ identification scheme is outside the scope of the present
+ document.
+ type: array
+ items:
+ description: >
+ An identifier with the intention of being globally
+ unique.
+ type: string
+ resourceTypes:
+ description: |
+ Match particular resource types.
+ type: array
+ items:
+ type: string
+ enum:
+ - COMPUTE
+ - STORAGE
+ - NETWORK
+ resourceGroupIds:
+ description: >
+ Match the "infrastructure resource groups" that are
+ logical groupings of the virtualised resources assigned to
+ a tenant within an infrastructure Domain.
+ type: array
+ items:
+ description: >
+ An identifier maintained by the VIM or other resource
+ provider. It is expected to be unique within the VIM
+ instance.
+ type: string
+ callbackUri:
+ description: |
+ String formatted according to IETF RFC 3986.
+ type: string
+ _links:
+ description: |
+ Links for this resource
+ type: object
+ required:
+ - self
+ properties:
+ self:
+ description: |
+ This type represents a link to a resource.
+ type: object
+ required:
+ - href
+ properties:
+ href:
+ description: |
+ URI of the referenced resource.
+ type: string
+ format: url
+ '400':
+ description: >
+ Bad Request
+
+ If the request is malformed or syntactically incorrect (e.g. if the
+ request URI contains incorrect query parameters or a syntactically
+ incorrect payload body), the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided, and
+ should include in the "detail" attribute more information about the
+ source of the problem.
+
+ ---
+
+ If the request contains a malformed access token, the API producer
+ should respond with this response. The details of the error shall be
+ returned in the WWW-Authenticate HTTP header, as defined in IETF RFC
+ 6750 and IETF RFC 7235. The ProblemDetails structure may be
+ provided.
+
+ ---
+
+ If there is an application error related to the client's input that
+ cannot be easily mapped to any other HTTP response code ("catch all
+ error"), the API producer shall respond with this response code.The
+ "ProblemDetails" structure shall be provided, and shall include in
+ the "detail" attribute more information about the source of the
+ problem.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '401':
+ description: >
+ Unauthorized
+
+ If the request contains no access token even though one is required,
+ or if the request contains an authorization token that is invalid
+ (e.g. expired or revoked), the API producer should respond with this
+ response. The details of the error shall be returned in the
+ WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF
+ RFC 7235. The ProblemDetails structure may be provided.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '403':
+ description: >
+ Forbidden
+
+ If the API consumer is not allowed to perform a particular request
+ to a particular resource, the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided. It
+ should include in the "detail" attribute information about the
+ source of the problem, and may indicate how to solve it.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '404':
+ description: >
+ Not Found
+
+ If 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.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '406':
+ description: >
+ Not Acceptable
+
+ If the "Accept" HTTP header does not contain at least one name of a
+ content type that is acceptable to the API producer, the API
+ producer shall respond with this response code. The "ProblemDetails"
+ structure may be omitted in that case.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '500':
+ description: >
+ Internal Server Error
+
+ If there is an application error not related to the client's input
+ that cannot be easily mapped to any other HTTP response code ("catch
+ all error"), the API producer shall respond withthis response code.
+ The "ProblemDetails" structure shall be provided, and shall include
+ in the "detail" attribute more information about the source of the
+ problem.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '503':
+ description: >
+ Service Unavailable
+
+ If the API producer encounters an internal overload situation of
+ itself or of a system it relies on, it should respond with this
+ response code, following the provisions in IETF RFC 7231 [13] for
+ the use of the "Retry-After" HTTP header and for the alternative to
+ refuse the connection. The "ProblemDetails" structure may be
+ omitted.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ delete:
+ description: |
+ Terminate subscription
+
+ The DELETE method terminates an individual subscription.
+ parameters:
+ - name: Authorization
+ description: |
+ The authorization token for the request. Reference: IETF RFC 7235
+ in: header
+ required: true
+ type: string
+ responses:
+ '204':
+ description: >
+ No Content
+
+ The subscription resource was deleted successfully. The response
+ body shall be empty.
+ headers:
+ Content-Type:
+ description: >
+ The MIME type of the body of the request. Reference: IETF RFC
+ 7231
+ type: string
+ maximum: 1
+ minimum: 1
+ '400':
+ description: >
+ Bad Request
+
+ If the request is malformed or syntactically incorrect (e.g. if the
+ request URI contains incorrect query parameters or a syntactically
+ incorrect payload body), the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided, and
+ should include in the "detail" attribute more information about the
+ source of the problem.
+
+ ---
+
+ If the request contains a malformed access token, the API producer
+ should respond with this response. The details of the error shall be
+ returned in the WWW-Authenticate HTTP header, as defined in IETF RFC
+ 6750 and IETF RFC 7235. The ProblemDetails structure may be
+ provided.
+
+ ---
+
+ If there is an application error related to the client's input that
+ cannot be easily mapped to any other HTTP response code ("catch all
+ error"), the API producer shall respond with this response code.The
+ "ProblemDetails" structure shall be provided, and shall include in
+ the "detail" attribute more information about the source of the
+ problem.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '401':
+ description: >
+ Unauthorized
+
+ If the request contains no access token even though one is required,
+ or if the request contains an authorization token that is invalid
+ (e.g. expired or revoked), the API producer should respond with this
+ response. The details of the error shall be returned in the
+ WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF
+ RFC 7235. The ProblemDetails structure may be provided.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '403':
+ description: >
+ Forbidden
+
+ If the API consumer is not allowed to perform a particular request
+ to a particular resource, the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided. It
+ should include in the "detail" attribute information about the
+ source of the problem, and may indicate how to solve it.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '405':
+ description: >
+ Method Not Allowed
+
+ If a particular HTTP method is not supported for a particular
+ resource, the API producer shall respond with this response code.
+ The "ProblemDetails" structure may be omitted in that case.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '406':
+ description: >
+ Not Acceptable
+
+ If the "Accept" HTTP header does not contain at least one name of a
+ content type that is acceptable to the API producer, the API
+ producer shall respond with this response code. The "ProblemDetails"
+ structure may be omitted in that case.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '500':
+ description: >
+ Internal Server Error
+
+ If there is an application error not related to the client's input
+ that cannot be easily mapped to any other HTTP response code ("catch
+ all error"), the API producer shall respond withthis response code.
+ The "ProblemDetails" structure shall be provided, and shall include
+ in the "detail" attribute more information about the source of the
+ problem.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '503':
+ description: >
+ Service Unavailable
+
+ If the API producer encounters an internal overload situation of
+ itself or of a system it relies on, it should respond with this
+ response code, following the provisions in IETF RFC 7231 [13] for
+ the use of the "Retry-After" HTTP header and for the alternative to
+ refuse the connection. The "ProblemDetails" structure may be
+ omitted.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ description: >
+ The definition of the general "ProblemDetails" data structure from
+ IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
+ general framework defined in IETF RFC 7807 [19], the "status" and
+ "detail" attributes are mandated to be included by the present
+ document, to ensure that the response contains additional textual
+ information about an error. IETF RFC 7807 [19] foresees
+ extensibility of the "ProblemDetails" type. It is possible that
+ particular APIs in the present document, or particular
+ implementations, define extensions to define additional attributes
+ that provide more information about the error. The description
+ column only provides some explanation of the meaning to Facilitate
+ understanding of the design. For a full description, see IETF RFC
+ 7807 [19].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ description: >
+ A URI reference according to IETF RFC 3986 [5] that identifies
+ the problem type. It is encouraged that the URI provides
+ human-readable documentation for the problem (e.g. using HTML)
+ when dereferenced. When this member is not present, its value
+ is assumed to be "about:blank".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+
diff --git a/SOL003/VirtualisedResourcesQuotaAvailableNotification-API_egm/Subscriptions.robot b/SOL003/VirtualisedResourcesQuotaAvailableNotification-API_egm/Subscriptions.robot
new file mode 100644
index 00000000..3dfa1ab1
--- /dev/null
+++ b/SOL003/VirtualisedResourcesQuotaAvailableNotification-API_egm/Subscriptions.robot
@@ -0,0 +1,96 @@
+*** Settings ***
+Resource variables.txt
+Library REST http://${NFVO_HOST}:${NFVO_PORT}
+... spec=SOL003-VirtualisedResourcesQuotaAvailableNotification-API.yaml
+Library OperatingSystem
+
+*** Test Cases ***
+Create a new subscription
+ Log Create subscription instance by POST to ${apiRoot}/${apiName}/${apiVersion}/subscriptions
+ Set Headers {"Accept":"${ACCEPT}"}
+ Set Headers {"Content-Type": "${CONTENT_TYPE}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ ${body}= Get File json/vrQuotaAvailSubscriptionRequest.json
+ Post ${apiRoot}/${apiName}/${apiVersion}/subscriptions ${body}
+ Output response
+ Integer response status 201
+ Log Status code validated
+
+Create a new Subscription - DUPLICATION
+ Log Trying to create a subscription with an already created content
+ Pass Execution If ${NFVO_DUPLICATION} == 0 NVFO is not permitting duplication. Skipping the test
+ Set Headers {"Accept": "${ACCEPT}"}
+ Set Headers {"Content-Type": "${CONTENT_TYPE}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
+ ${body}= Get File json/vrQuotaAvailSubscriptionRequest.json
+ Post ${apiRoot}/${apiName}/${apiVersion}/subscriptions ${body}
+ Output response
+ Integer response status 201
+ Log Status code validated
+
+Create a new Subscription - NO-DUPLICATION
+ Log Trying to create a subscription with an already created content
+ Pass Execution If ${NFVO_DUPLICATION} == 1 VNFM permits duplication. Skipping the test
+ Set Headers {"Accept": "${ACCEPT}"}
+ Set Headers {"Content-Type": "${CONTENT_TYPE}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
+ ${body}= Get File json/vrQuotaAvailSubscriptionRequest.json
+ Post ${apiRoot}/${apiName}/${apiVersion}/subscriptions ${body}
+ Output response
+ Integer response status 303
+ Log Status code validated
+
+GET Subscriptions
+ Log Get the list of active subscriptions
+ Set Headers {"Accept":"${ACCEPT}"}
+ Set Headers {"Content-Type": "${CONTENT_TYPE}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ Log Execute Query and validate response
+ Get ${apiRoot}/${apiName}/${apiVersion}/subscriptions
+ Output response
+ Log Validate Status code
+ Integer response status 200
+
+GET Subscription - Filter
+ Log Get the list of active subscriptions using a filter
+ Set Headers {"Accept": "${ACCEPT}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
+ GET ${apiRoot}/${apiName}/${apiVersion}/subscriptions?${sub_filter}
+ Integer response status 200
+ Log Received a 200 OK as expected
+
+GET subscriptions - Bad Request Invalid attribute-based filtering parameters
+ Log Get the list of active subscriptions using an invalid filter
+ Set Headers {"Accept": "${ACCEPT}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"}
+ GET ${apiRoot}/${apiName}/${apiVersion}/subscriptions?${sub_filter_invalid}
+ Integer response status 400
+ Log Received a 400 Bad Request as expected
+
+PUT subscriptions - Method not implemented
+ log Trying to perform a PUT. This method should not be implemented
+ Set Headers {"Accept":"${ACCEPT}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ Put ${apiRoot}/${apiName}/${apiVersion}/subscriptions
+ Log Validate Status code
+ Output response
+ Integer response status 405
+
+PATCH subscriptions - Method not implemented
+ log Trying to perform a PATCH. This method should not be implemented
+ Set Headers {"Accept":"${ACCEPT}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ Patch ${apiRoot}/${apiName}/${apiVersion}/subscriptions
+ Log Validate Status code
+ Output response
+ Integer response status 405
+
+DELETE subscriptions - Method not implemented
+ log Trying to perform a DELETE. This method should not be implemented
+ Set Headers {"Accept":"${ACCEPT}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ Delete ${apiRoot}/${apiName}/${apiVersion}/subscriptions
+ Log Validate Status code
+ Output response
+ Integer response status 405
+
\ No newline at end of file
diff --git a/SOL003/VirtualisedResourcesQuotaAvailableNotification-API_egm/jsons/vrQuotaAvailSubscriptionRequest .json b/SOL003/VirtualisedResourcesQuotaAvailableNotification-API_egm/jsons/vrQuotaAvailSubscriptionRequest .json
new file mode 100644
index 00000000..8d91c2b8
--- /dev/null
+++ b/SOL003/VirtualisedResourcesQuotaAvailableNotification-API_egm/jsons/vrQuotaAvailSubscriptionRequest .json
@@ -0,0 +1,3 @@
+{
+ "callbackUri": "http://127.0.0.1/subscribe"
+}
\ No newline at end of file
diff --git a/SOL003/VirtualisedResourcesQuotaAvailableNotification-API_egm/variables.txt b/SOL003/VirtualisedResourcesQuotaAvailableNotification-API_egm/variables.txt
new file mode 100644
index 00000000..6e2f7465
--- /dev/null
+++ b/SOL003/VirtualisedResourcesQuotaAvailableNotification-API_egm/variables.txt
@@ -0,0 +1,36 @@
+*** Variables ***
+${VNFM_HOST} localhost # Hostname of the VNFM
+${VNFM_PORT} 8080 # Listening port of the VNFM
+${NFVO_HOST} localhost # Hostname of the NFVO
+${NFVO_PORT} 8081 # Listening port of the NFVO
+${VNFM_SCHEMA} https
+${NFVO_SCHEMA} https
+${AUTHORIZATION} Bearer QWxhZGRpbjpvcGVuIHNlc2FtZQ==
+${CONTENT_TYPE} application/json
+${CONTENT_TYPE_PATCH} application/merge-patch+json
+${ACCEPT} application/json
+${apiRoot} /
+${apiName} vrqan
+${apiVersion} v1
+${AUTH_USAGE} 1
+${WRONG_AUTHORIZATION} Bearer XXXXXWRONGXXXXX
+${alarm_filter} managedObjectId
+${managedObjectId} 007c111c-38a1-42c0-a666-7475ecb1567c
+${invalid_alarm_filter} badFilter
+${alarmId} 6fc3539c-e602-4afa-8e13-962fb5a7d81d
+${vnfInstanceDescription} description vnf
+${vnfInstanceDescription_Update} Updated description vnf
+${SINGLE_FILE_VNFD} 1 # If VNFD is PLAIN TEXT
+${ACCEPT_PLAIN} text/plain
+${ACCEPT_ZIP} application/zip
+${vnfPkgId_processing} 007c111c-38a1-42c0-a666-7475ecb1567c
+${ARTIFACT_TYPE} application/octet-stream
+${ARTIFACT_ID} artifactId
+${WRONG_ACCEPT} application/json
+${vnfLcmOpOccId} 6fc3539c-e602-4afa-8e13-962fb5a7d81d
+${NFVO_DUPLICATION} 0
+${sub_filter} filter
+${sub_filter_invalid} filter_invalid
+${subscriptionId} 6fc3539c-e602-4afa-8e13-962fb5a7d81f
+${notification_ep} notification
+${VrQuotaAvailNotification} {}
\ No newline at end of file
diff --git a/TrackingStatus.txt b/TrackingStatus.txt
index 2b451b04..94f3e38a 100644
--- a/TrackingStatus.txt
+++ b/TrackingStatus.txt
@@ -26,9 +26,12 @@ SOL002
SOL003
- - VirtualisedResourcesQuotaAvailableNotification-API_egm --> [NOT STARTED]
+ - VirtualisedResourcesQuotaAvailableNotification-API_egm --> [DONE]
+ * Subscriptions --------------------------------------------> [DONE]
+ * IndividualSubscription -----------------------------------> [DONE]
+ * NotificationEndpoint -------------------------------------> [DONE] //to be reviewed with nxw on how notification server will be configured
- - VNFFaultManagement-API_egm ------------------------------> [IN PROGRESS]
+ - VNFFaultManagement-API_egm ------------------------------> [DONE]
* Alarms ----------------------------------------------> [DONE]
* IndividualAlarm ----------------------------------------------> [DONE]
* Subscriptions --------------------------------------------> [DONE]
--
GitLab