From f05476a675befa27a3aad942a96f1739e58db553 Mon Sep 17 00:00:00 2001 From: uihassan Date: Tue, 7 Jul 2020 10:40:27 +0500 Subject: [PATCH 01/22] variables added --- .gitignore | 1 + .../environment/variables.txt | 17 ++++++++++ .../schemas/ProblemDetails.schema.json | 34 +++++++++++++++++++ 3 files changed, 52 insertions(+) create mode 100644 SOL009/NFVMANOFaultManagement-API/environment/variables.txt create mode 100644 SOL009/NFVMANOFaultManagement-API/schemas/ProblemDetails.schema.json diff --git a/.gitignore b/.gitignore index a40199d34..3667399ca 100644 --- a/.gitignore +++ b/.gitignore @@ -3,3 +3,4 @@ /red.xml build/ dist/ +/libspecs/ diff --git a/SOL009/NFVMANOFaultManagement-API/environment/variables.txt b/SOL009/NFVMANOFaultManagement-API/environment/variables.txt new file mode 100644 index 000000000..71a0f5511 --- /dev/null +++ b/SOL009/NFVMANOFaultManagement-API/environment/variables.txt @@ -0,0 +1,17 @@ +*** Variables *** +${NFVMANO_HOST} localhost # Hostname of the NFV-MANO +${NFVMANO_PORT} 8080 # Listening port of the NFV-MANO +${NFVMANO_SCHEMA} https +${AUTHORIZATION} Bearer QWxhZGRpbjpvcGVuIHNlc2FtZQ== +${CONTENT_TYPE} application/json +${ACCEPT} application/json +${ACCEPT_JSON} application/json +${AUTH_USAGE} 1 + +${WRONG_AUTHORIZATION} Bearer XXXXXWRONGXXXXX +${apiRoot} / +${apiName} nfvmanofm +${apiVersion} v1 + + + diff --git a/SOL009/NFVMANOFaultManagement-API/schemas/ProblemDetails.schema.json b/SOL009/NFVMANOFaultManagement-API/schemas/ProblemDetails.schema.json new file mode 100644 index 000000000..62f176127 --- /dev/null +++ b/SOL009/NFVMANOFaultManagement-API/schemas/ProblemDetails.schema.json @@ -0,0 +1,34 @@ +{ + "definitions": {}, + "$schema": "http://json-schema.org/draft-07/schema#", + "type": "object", + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "properties": { + "type": { + "type": "string", + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "format": "URI" + }, + "title": { + "type": "string", + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n" + }, + "status": { + "type": "integer", + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n" + }, + "detail": { + "type": "string", + "description": "A human-readable explanation specific to this occurrence of the problem.\n" + }, + "instance": { + "type": "string", + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "format": "URI" + } + }, + "required": [ + "status", + "detail" + ] +} \ No newline at end of file -- GitLab From c661e18298aa7744048090dbd72f52a5085f6b90 Mon Sep 17 00:00:00 2001 From: uihassan Date: Wed, 8 Jul 2020 07:19:24 +0500 Subject: [PATCH 02/22] Added Test Case for Alarms.robot --- .../NFVMANOFaultManagement-API/Alarms.robot | 125 ++++++++++++++++++ .../FaultManagement-APIKeyword.robot | 95 +++++++++++++ .../environment/variables.txt | 8 +- 3 files changed, 227 insertions(+), 1 deletion(-) create mode 100644 SOL009/NFVMANOFaultManagement-API/Alarms.robot create mode 100644 SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot diff --git a/SOL009/NFVMANOFaultManagement-API/Alarms.robot b/SOL009/NFVMANOFaultManagement-API/Alarms.robot new file mode 100644 index 000000000..85e1dc22a --- /dev/null +++ b/SOL009/NFVMANOFaultManagement-API/Alarms.robot @@ -0,0 +1,125 @@ +*** Settings *** +Resource environment/variables.txt +Resource FaultManagement-APIKeyword.robot +Library REST ${NFVMANO_SCHEMA}://${NFVMANO_HOST}:${NFVMANO_PORT} +Library JSONLibrary +Library JSONSchemaLibrary schemas/ +Library OperatingSystem + + +*** Test Cases *** +POST Alarms - Method not implemented + [Documentation] Test ID: 8.3.3.1.1 + ... Test title: POST Alarms - Method not implemented + ... Test objective: The objective is to test that Post method is not allowed to create Fault management alarms on NFV-MANO + ... Pre-conditions: none + ... Reference: clause 7.5.3.3.1 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + Send POST request for fault management Alarms + Check HTTP Response Status Code Is 405 + +Get information about multiple alarms + [Documentation] Test ID: 8.3.3.1.2 + ... Test title: Get information about multiple alarms + ... Test objective: The objective is to retrieve information about the alarm list and perform a JSON schema and content validation of the returned alarms data structure + ... Pre-conditions: none + ... Reference: clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + GET Fault Management Alarms + Check HTTP Response Status Code Is 200 + Check HTTP Response Body Json Schema Is Alarms + +Get information about multiple alarms with filter + [Documentation] Test ID: 8.3.3.1.3 + ... Test title: Get information about multiple alarms with filter + ... Test objective: The objective is to retrieve information about the alarm list and perform a JSON schema and content validation of the returned alarms data structure, and verify that the retrieved information matches the issued attribute-based filters + ... Pre-conditions: none + ... Reference: clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + GET Fault Management Alarms With Filters + Check HTTP Response Status Code Is 200 + Check HTTP Response Body Json Schema Is Alarms + +Get information about multiple alarms Bad Request Invalid attribute-based filtering parameters + [Documentation] Test ID: 8.3.3.1.4 + ... Test title: Get information about multiple alarms Bad Request Invalid attribute-based filtering parameters + ... Test objective: The objective is to try to retrieve information about the alarm list with invalid filters and perform a JSON schema and content validation of the returned problem details data structure + ... Pre-conditions: none + ... Reference: clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + GET Fault Management Alarms With Invalid Filters + Check HTTP Response Status Code Is 400 + Check HTTP Response Body Json Schema Is ProblemDetails + + +Get information about multiple alarms as a Paged Response + [Documentation] Test ID: 8.3.3.1.5 + ... Test title: Get information about multiple alarms as a Paged Response + ... Test objective: The objective is to retrieve information about the alarm list as a Paged Response + ... Pre-conditions: none + ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + GET Fault Management Alarms + Check HTTP Response Status Code Is 200 + Check LINK in Header + +Get information about multiple alarms - Bad Request Response too Big + [Documentation] Test ID: 8.3.3.1.6 + ... Test title: Get information about multiple alarms - Bad Request Response too Big + ... Test objective: The objective is to try to retrieve information about the alarm list because response is too big and perform a JSON schema and content validation of the returned problem details data structure + ... Pre-conditions: none + ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + GET Fault Management Alarms + Check HTTP Response Status Code Is 400 + Check HTTP Response Body Json Schema Is ProblemDetails + +PUT Alarms - Method not implemented + [Documentation] Test ID: 8.3.3.1.7 + ... Test title: PUT Alarms - Method not implemented + ... Test objective: The objective is to test that PUT method is not allowed to for Fault management alarms on NFV-MANO + ... Pre-conditions: none + ... Reference: clause 7.5.3.3.3 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + PUT Fault management Alarms + Check HTTP Response Status Code Is 405 + +PATCH Alarms - Method not implemented + [Documentation] Test ID: 8.3.3.1.8 + ... Test title: PATCH Alarms - Method not implemented + ... Test objective: The objective is to test that PATCH method is not allowed to for Fault management alarms on NFV-MANO + ... Pre-conditions: none + ... Reference: clause 7.5.3.3.4 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + PATCH Fault management Alarms + Check HTTP Response Status Code Is 405 + +DELETE Alarms - Method not implemented + [Documentation] Test ID: 8.3.3.1.9 + ... Test title: POST Alarms - Method not implemented + ... Test objective: The objective is to test that DELETE method is not allowed for Fault management alarms on NFV-MANO + ... Pre-conditions: none + ... Reference: clause 7.5.3.3.5 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + DELETE Fault management Alarms + Check HTTP Response Status Code Is 405 + Check Postcondition NFV-MANO fault management alarms Exists + \ No newline at end of file diff --git a/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot b/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot new file mode 100644 index 000000000..f2e0d5bfa --- /dev/null +++ b/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot @@ -0,0 +1,95 @@ +*** Settings *** +Resource environment/variables.txt +Library REST ${NFVMANO_SCHEMA}://${NFVMANO_HOST}:${NFVMANO_PORT} +Library JSONLibrary +Library JSONSchemaLibrary schemas/ +Library OperatingSystem + + +Library Process + +*** Variables *** + + +*** Keywords *** + +Send POST request for fault management Alarms + 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}/${apiMajorVersion}/alarms + ${outputResponse}= Output response + Set Global Variable @{response} ${outputResponse} + +Check HTTP Response Status Code Is + [Arguments] ${expected_status} + Log Validate Status code + Should Be Equal ${response[0]['status']} ${expected_status} + Log Status code validated + +GET Fault Management Alarms + Log Query NFVO The GET method queries information about multiple alarms. + Set Headers {"Accept":"${ACCEPT}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} + Log Execute Query + Get ${apiRoot}/${apiName}/${apiMajorVersion}/alarms + ${outputResponse}= Output response + Set Global Variable @{response} ${outputResponse} + +Check HTTP Response Body Json Schema Is + [Arguments] ${input} + ${schema} = Catenate ${input} .schema.json + Validate Json ${schema} ${response[0]['body']} + Log Json Schema Validation OK + +GET Fault Management Alarms With Filters + Log Query NFVO The GET method queries information about multiple alarms with filters. + Set Headers {"Accept":"${ACCEPT}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} + Log Execute Query + Get ${apiRoot}/${apiName}/${apiMajorVersion}/alarms?${alarm_filter}=${managedObjectId} + ${outputResponse}= Output response + Set Global Variable @{response} ${outputResponse} + +GET Fault Management Alarms With Invalid Filters + Log Query NFVO The GET method queries information about multiple alarms with filters. + Set Headers {"Accept":"${ACCEPT}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} + Log Execute Query + Get ${apiRoot}/${apiName}/${apiMajorVersion}/alarms?${invalid_alarm_filter}=${managedObjectId} + ${outputResponse}= Output response + Set Global Variable @{response} ${outputResponse} + +Check LINK in Header + ${linkURL}= Get Value From Json ${response['headers']} $..Link + Should Not Be Empty ${linkURL} + +PATCH Fault management Alarms + 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}/${apiMajorVersion}/alarms + ${outputResponse} = Output response + Set Global Variable @{response} ${outputResponse} + +PUT Fault management Alarms + 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}/${apiMajorVersion}/alarms + ${outputResponse}= Output response + Set Global Variable @{response} ${outputResponse} + +DELETE Fault management Alarms + 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}/${apiMajorVersion}/alarms + ${outputResponse}= Output response + Set Global Variable @{response} ${outputResponse} + +Check Postcondition NFV-MANO fault management alarms Exists + Log Checking that alarms exists + GET Fault Management Alarms + Check HTTP Response Status Code Is 200 + Check HTTP Response Body Json Schema Is Alarms \ No newline at end of file diff --git a/SOL009/NFVMANOFaultManagement-API/environment/variables.txt b/SOL009/NFVMANOFaultManagement-API/environment/variables.txt index 71a0f5511..83f640338 100644 --- a/SOL009/NFVMANOFaultManagement-API/environment/variables.txt +++ b/SOL009/NFVMANOFaultManagement-API/environment/variables.txt @@ -11,7 +11,13 @@ ${AUTH_USAGE} 1 ${WRONG_AUTHORIZATION} Bearer XXXXXWRONGXXXXX ${apiRoot} / ${apiName} nfvmanofm -${apiVersion} v1 +${apiMajorVersion} v1 + +${response} {} + +${alarm_filter} managedObjectId +${managedObjectId} 007c111c-38a1-42c0-a666-7475ecb1567c +${invalid_alarm_filter} badFilter -- GitLab From 88a4ba460a769c73e61d40754b488580660ba00c Mon Sep 17 00:00:00 2001 From: uihassan Date: Wed, 8 Jul 2020 12:10:37 +0500 Subject: [PATCH 03/22] Added Test Cases for IndiviualAlarm.robot --- .../FaultManagement-APIKeyword.robot | 78 ++++++++++++- .../IndividualAlarm.robot | 104 ++++++++++++++++++ .../environment/variables.txt | 8 ++ 3 files changed, 188 insertions(+), 2 deletions(-) create mode 100644 SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot diff --git a/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot b/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot index f2e0d5bfa..9633d085f 100644 --- a/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot +++ b/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot @@ -9,7 +9,7 @@ Library OperatingSystem Library Process *** Variables *** - +${original_etag} 1234 *** Keywords *** @@ -92,4 +92,78 @@ Check Postcondition NFV-MANO fault management alarms Exists Log Checking that alarms exists GET Fault Management Alarms Check HTTP Response Status Code Is 200 - Check HTTP Response Body Json Schema Is Alarms \ No newline at end of file + Check HTTP Response Body Json Schema Is Alarms + +Send POST request for fault management Individual Alarm + 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}"} + Post ${apiRoot}/${apiName}/${apiMajorVersion}/alarms/${alarmId} + ${outputResponse}= Output response + Set Global Variable @{response} ${outputResponse} + +GET Fault Management Individual Alarm + Log Query VNF The GET method queries information about an alarm. + 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}/${apiMajorVersion}/alarms/${alarmId} + ${etag} Output response headers ETag + Set Suite Variable &{original_etag} ${etag} + ${outputResponse}= Output response + Set Global Variable @{response} ${outputResponse} + +PUT Fault Management Individual Alarm + 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}/${apiMajorVersion}/alarms/${alarmId} + ${outputResponse}= Output response + Set Global Variable @{response} ${outputResponse} + +Check Postcondition fault management individual alarm Exists + Log Checking that individual alarm exists + GET Fault Management Individual Alarm + Check HTTP Response Status Code Is 200 + Check HTTP Response Body Json Schema Is alarm + +PATCH Fault Management Individual Alarm + log Trying to perform a PATCH. This method modifies an individual alarm resource + Set Headers {"Accept":"${ACCEPT}"} + Set Headers {"Content-Type": "${CONTENT_TYPE_PATCH}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} + ${body}= Get File jsons/alarmModifications.json + Patch ${apiRoot}/${apiName}/${apiMajorVersion}/alarms/${alarmId} ${body} + ${outputResponse}= Output response + Set Global Variable @{response} ${outputResponse} + +PATCH Fault Management Individual Alarm - precondition failed + log Trying to perform a PATCH. This method modifies an individual alarm resource + Set Headers {"Accept":"${ACCEPT}"} + Set Headers {"Content-Type": "${CONTENT_TYPE_PATCH}"} + Set Headers {"If-Match": "${original_etag[0]}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} + ${body}= Get File jsons/alarmModifications.json + Patch ${apiRoot}/${apiName}/${apiMajorVersion}/alarms/${alarmId} ${body} + ${outputResponse}= Output response + Set Global Variable @{response} ${outputResponse} + +PATCH Fault Management Individual Alarm Conflict + log Trying to perform a PATCH. This method modifies an individual alarm resource + Set Headers {"Accept":"${ACCEPT}"} + Set Headers {"Content-Type": "${CONTENT_TYPE_PATCH}"} + Set Headers {"If-Match": "${Etag}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} + ${body}= Get File jsons/alarmModifications.json + Patch ${apiRoot}/${apiName}/${apiMajorVersion}/alarms/${alarmId} ${body} + ${outputResponse}= Output response + Set Global Variable @{response} ${outputResponse} + +DELETE Fault Management Individual Alarm + 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}/${apiMajorVersion}/alarms/${alarmId} + ${outputResponse}= Output response + Set Global Variable @{response} ${outputResponse} \ No newline at end of file diff --git a/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot b/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot new file mode 100644 index 000000000..bd96fbc20 --- /dev/null +++ b/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot @@ -0,0 +1,104 @@ +*** Settings *** +Resource environment/variables.txt +Resource FaultManagement-APIKeyword.robot +Library REST ${NFVMANO_SCHEMA}://${NFVMANO_HOST}:${NFVMANO_PORT} +Library OperatingSystem +Library JSONLibrary +Library JSONSchemaLibrary schemas/ +Library DependencyLibrary + + + +*** Test Cases *** +POST Alarm - Method not implemented + [Documentation] Test ID: 8.3.3.2.1 + ... Test title: POST Alarm - Method not implemented + ... Test objective: The objective is to test that Post method is not allowed to create Fault management individual alarm on NFV-MANO + ... Pre-conditions: none + ... Reference: clause 7.5.4.3.1 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + Send POST request for fault management Individual Alarm + Check HTTP Response Status Code Is 405 + +Get information about an fault management individual alarm + [Documentation] Test ID: 8.3.3.2.2 + ... Test title: Get information about an fault management individual alarm + ... Test objective: The objective is to retrieve information about an individual alarm and perform a JSON schema and content validation of the returned alarm data structure + ... Pre-conditions: The related alarm exists + ... Reference: clause 7.5.4.3.2 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + GET Fault Management Individual Alarm + Check HTTP Response Status Code Is 200 + Check HTTP Response Body Json Schema Is alarm + +PUT Alarm - Method not implemented + [Documentation] Test ID: 8.3.3.2.3 + ... Test title: PUT Alarm - Method not implemented + ... Test objective: he objective is to test that PUT method is not allowed to for Fault management individual alarm on NFV-MANO + ... Pre-conditions: The related alarm exists + ... Reference: clause 7.5.4.3.3 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + PUT Fault Management Individual Alarm + Check HTTP Response Status Code Is 405 + +PATCH Fault Management Individual Alarm + [Documentation] Test ID: 8.3.3.2.4 + ... Test title: PATCH Fault Management Individual Alarm + ... Test objective: The objective is to Modify an individual alarm resource and perform a JSON schema and content validation of the returned alarm data structure + ... Pre-conditions: The related alarm exists + ... Reference: clause 7.5.4.3.4 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + Check Postcondition fault management individual alarm Exists + PATCH Fault Management Individual Alarm + Check HTTP Response Status Code Is 200 + Check HTTP Response Body Json Schema Is alarmModification + +Modify an individual alarm resource - Precondition failed + [Documentation] Test ID: 8.3.3.2.5 + ... Test title: Modify an individual alarm resource - Precondition failed + ... Test objective: The objective is to test that an individual alarm resource cannot be modified if the alarm is already in the state that is requested to be set + ... Pre-conditions: The related alarm exists + ... Reference: clause 7.5.4.3.4 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + Check Postcondition fault management individual alarm Exists + PATCH Fault Management Individual Alarm - precondition failed + Check HTTP Response Status Code Is 409 + Check HTTP Response Body Json Schema Is ProblemDetails + +Modify an individual alarm resource - Conflict + [Documentation] Test ID: 8.3.3.2.6 + ... Test title: Modify an individual alarm resource - Conflict + ... Test objective: The objective is to test that an individual alarm resource cannot be modified if the resource was modified by another entity + ... Pre-conditions: The related alarm exists + ... Reference: clause 7.5.4.3.4 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + Depends On Test PATCH Fault Management Individual Alarm + Check Postcondition fault management individual alarm Exists + PATCH Fault Management Individual Alarm Conflict + Check HTTP Response Status Code Is 412 + Check HTTP Response Body Json Schema Is ProblemDetails + +DELETE Alarm - Method not implemented + [Documentation] Test ID: 8.3.3.2.7 + ... Test title: DELETE Alarm - Method not implemented + ... Test objective: The objective is to test that DELETE method is not allowed to for Fault management individual alarm on NFV-MANO + ... Pre-conditions: nona + ... Reference: clause 7.5.4.3.5 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: The individual alarm still exists + DELETE Fault Management Individual Alarm + Check HTTP Response Status Code Is 405 + Check Postcondition fault management individual alarm Exists \ No newline at end of file diff --git a/SOL009/NFVMANOFaultManagement-API/environment/variables.txt b/SOL009/NFVMANOFaultManagement-API/environment/variables.txt index 83f640338..f06277a9a 100644 --- a/SOL009/NFVMANOFaultManagement-API/environment/variables.txt +++ b/SOL009/NFVMANOFaultManagement-API/environment/variables.txt @@ -14,10 +14,18 @@ ${apiName} nfvmanofm ${apiMajorVersion} v1 ${response} {} +${CONTENT_TYPE_PATCH} application/merge-patch+json ${alarm_filter} managedObjectId ${managedObjectId} 007c111c-38a1-42c0-a666-7475ecb1567c ${invalid_alarm_filter} badFilter +${alarmId} 6fc3539c-e602-4afa-8e13-962fb5a7d81d + +${Etag}= an etag +${Etag_modified}= a modified etag + + + -- GitLab From 6b6107d54dac34d010414bc85412fc868c580abb Mon Sep 17 00:00:00 2001 From: uihassan Date: Thu, 9 Jul 2020 07:08:45 +0500 Subject: [PATCH 04/22] Added Schemas --- .../IndividualAlarm.robot | 2 +- .../schemas/AlarmModification.schema.json | 16 ++ .../schemas/Alarms.schema.json | 171 ++++++++++++++++++ .../schemas/alarm.schema.json | 168 +++++++++++++++++ 4 files changed, 356 insertions(+), 1 deletion(-) create mode 100644 SOL009/NFVMANOFaultManagement-API/schemas/AlarmModification.schema.json create mode 100644 SOL009/NFVMANOFaultManagement-API/schemas/Alarms.schema.json create mode 100644 SOL009/NFVMANOFaultManagement-API/schemas/alarm.schema.json diff --git a/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot b/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot index bd96fbc20..ab533b017 100644 --- a/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot +++ b/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot @@ -59,7 +59,7 @@ PATCH Fault Management Individual Alarm Check Postcondition fault management individual alarm Exists PATCH Fault Management Individual Alarm Check HTTP Response Status Code Is 200 - Check HTTP Response Body Json Schema Is alarmModification + Check HTTP Response Body Json Schema Is AlarmModification Modify an individual alarm resource - Precondition failed [Documentation] Test ID: 8.3.3.2.5 diff --git a/SOL009/NFVMANOFaultManagement-API/schemas/AlarmModification.schema.json b/SOL009/NFVMANOFaultManagement-API/schemas/AlarmModification.schema.json new file mode 100644 index 000000000..8075efd71 --- /dev/null +++ b/SOL009/NFVMANOFaultManagement-API/schemas/AlarmModification.schema.json @@ -0,0 +1,16 @@ +{ + "description": "This type represents attribute modifications for an \"Individual alarm\" resource, i.e. modifications to a resource representation based on the \"Alarm\" data type. The attributes of \"Alarm\" that can be modified are included in the \"AlarmModifications\" data type.\n", + "type": "object", + "required": [ + "ackState" + ], + "properties": { + "ackState": { + "description": "New value of the \"ackState\" attribute in \"Alarm\". Permitted values: * ACKNOWLEDGED\n", + "type": "string", + "enum": [ + "ACKNOWLEDGED" + ] + } + } + } \ No newline at end of file diff --git a/SOL009/NFVMANOFaultManagement-API/schemas/Alarms.schema.json b/SOL009/NFVMANOFaultManagement-API/schemas/Alarms.schema.json new file mode 100644 index 000000000..612a328d2 --- /dev/null +++ b/SOL009/NFVMANOFaultManagement-API/schemas/Alarms.schema.json @@ -0,0 +1,171 @@ +{ + "type": "array", + "items": { + "description": "The alarm data type encapsulates information about an alarm.\n", + "type": "object", + "required": [ + "id", + "managedObjectId", + "alarmRaisedTime", + "ackState", + "perceivedSeverity", + "eventTime", + "eventType", + "probableCause", + "isRootCause", + "_links" + ], + "properties": { + "id": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "managedObjectId": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "associatedFaultyInstanceId": { + "description": "This type represents the identifier to reference a managed object of a particular type. \n", + "type": "object", + "properties": { + "type": { + "description": "Indicates the type of managed object. Permitted values:\n - MANO_ENTITY\n - MANO_SERVICE\n - MANO_SERVICE_IF\n - CONSUMED_MANO_IF\n - MANO_ENTITY_COMPONENT\n\nThe \"MANO_ENTITY COMPONENT\" is only applicable if attribute \"manoEntityComponents\" in \"ManoEntity\" is supported by the API producer.\n", + "type": "string", + "enum": [ + "MANO_ENTITY", + "MANO_SERVICE", + "MANO_SERVICE_IF", + "CONSUMED_MANO_IF", + "MANO_ENTITY_COMPONENT" + ] + }, + "objectId": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "subObjectId": { + "description": "An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n", + "type": "string" + } + }, + "required": [ + "type", + "objectId" + ] + }, + "alarmRaisedTime": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "alarmChangedTime": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "alarmClearedTime": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "ackState": { + "description": "Acknowledgement state of the alarm. Permitted values: * UNACKNOWLEDGED * ACKNOWLEDGED.\n", + "type": "string", + "enum": [ + "UNACKNOWLEDGED", + "ACKNOWLEDGED" + ] + }, + "perceivedSeverity": { + "description": "Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service\n affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting\n condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a\n non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a\n potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the\n severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or\n more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "CRITICAL", + "MAJOR", + "MINOR", + "WARNING", + "INDETERMINATE", + "CLEARED" + ] + }, + "eventTime": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "eventType": { + "description": "The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the\n procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a\n software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a\n condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the\n quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment\n fault (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "COMMUNICATIONS_ALARM", + "PROCESSING_ERROR_ALARM", + "ENVIRONMENTAL_ALARM", + "QOS_ALARM", + "EQUIPMENT_ALARM" + ] + }, + "faultType": { + "description": "Additional information to clarify the type of the fault.\n", + "type": "string" + }, + "probableCause": { + "description": "Information about the probable cause of the fault.\n", + "type": "string" + }, + "isRootCause": { + "description": "Attribute indicating if this fault is the root for other correlated alarms. If true, then the alarms listed in the attribute CorrelatedAlarmId are caused by this fault.\n", + "type": "boolean" + }, + "correlatedAlarmIds": { + "description": "List of identifiers of other alarms correlated to this fault.\n", + "type": "array", + "items": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + } + }, + "faultDetails": { + "description": "Provides additional information about the fault.\n", + "type": "array", + "items": { + "type": "string" + } + }, + "_links": { + "description": "Links for this resource.\n", + "type": "object", + "required": [ + "self" + ], + "properties": { + "self": { + "description": "This type represents a link to a resource using an absolute URI.\n", + "type": "object", + "required": [ + "href" + ], + "properties": { + "href": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + } + } + }, + "objectInstance": { + "description": "This type represents a link to a resource using an absolute URI.\n", + "type": "object", + "required": [ + "href" + ], + "properties": { + "href": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + } + } + } + } + } + } + } +} \ No newline at end of file diff --git a/SOL009/NFVMANOFaultManagement-API/schemas/alarm.schema.json b/SOL009/NFVMANOFaultManagement-API/schemas/alarm.schema.json new file mode 100644 index 000000000..51a3853d1 --- /dev/null +++ b/SOL009/NFVMANOFaultManagement-API/schemas/alarm.schema.json @@ -0,0 +1,168 @@ +{ + "description": "The alarm data type encapsulates information about an alarm.\n", + "type": "object", + "required": [ + "id", + "managedObjectId", + "alarmRaisedTime", + "ackState", + "perceivedSeverity", + "eventTime", + "eventType", + "probableCause", + "isRootCause", + "_links" + ], + "properties": { + "id": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "managedObjectId": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "associatedFaultyInstanceId": { + "description": "This type represents the identifier to reference a managed object of a particular type. \n", + "type": "object", + "properties": { + "type": { + "description": "Indicates the type of managed object. Permitted values:\n - MANO_ENTITY\n - MANO_SERVICE\n - MANO_SERVICE_IF\n - CONSUMED_MANO_IF\n - MANO_ENTITY_COMPONENT\n\nThe \"MANO_ENTITY COMPONENT\" is only applicable if attribute \"manoEntityComponents\" in \"ManoEntity\" is supported by the API producer.\n", + "type": "string", + "enum": [ + "MANO_ENTITY", + "MANO_SERVICE", + "MANO_SERVICE_IF", + "CONSUMED_MANO_IF", + "MANO_ENTITY_COMPONENT" + ] + }, + "objectId": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "subObjectId": { + "description": "An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n", + "type": "string" + } + }, + "required": [ + "type", + "objectId" + ] + }, + "alarmRaisedTime": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "alarmChangedTime": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "alarmClearedTime": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "ackState": { + "description": "Acknowledgement state of the alarm. Permitted values: * UNACKNOWLEDGED * ACKNOWLEDGED.\n", + "type": "string", + "enum": [ + "UNACKNOWLEDGED", + "ACKNOWLEDGED" + ] + }, + "perceivedSeverity": { + "description": "Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service\n affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting\n condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a\n non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a\n potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the\n severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or\n more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "CRITICAL", + "MAJOR", + "MINOR", + "WARNING", + "INDETERMINATE", + "CLEARED" + ] + }, + "eventTime": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "eventType": { + "description": "The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the\n procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a\n software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a\n condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the\n quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment\n fault (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "COMMUNICATIONS_ALARM", + "PROCESSING_ERROR_ALARM", + "ENVIRONMENTAL_ALARM", + "QOS_ALARM", + "EQUIPMENT_ALARM" + ] + }, + "faultType": { + "description": "Additional information to clarify the type of the fault.\n", + "type": "string" + }, + "probableCause": { + "description": "Information about the probable cause of the fault.\n", + "type": "string" + }, + "isRootCause": { + "description": "Attribute indicating if this fault is the root for other correlated alarms. If true, then the alarms listed in the attribute CorrelatedAlarmId are caused by this fault.\n", + "type": "boolean" + }, + "correlatedAlarmIds": { + "description": "List of identifiers of other alarms correlated to this fault.\n", + "type": "array", + "items": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + } + }, + "faultDetails": { + "description": "Provides additional information about the fault.\n", + "type": "array", + "items": { + "type": "string" + } + }, + "_links": { + "description": "Links for this resource.\n", + "type": "object", + "required": [ + "self" + ], + "properties": { + "self": { + "description": "This type represents a link to a resource using an absolute URI.\n", + "type": "object", + "required": [ + "href" + ], + "properties": { + "href": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + } + } + }, + "objectInstance": { + "description": "This type represents a link to a resource using an absolute URI.\n", + "type": "object", + "required": [ + "href" + ], + "properties": { + "href": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + } + } + } + } + } + } + } \ No newline at end of file -- GitLab From b9a51075da3a5c78009a22ef7d0b0e0fd154c43d Mon Sep 17 00:00:00 2001 From: uihassan Date: Thu, 9 Jul 2020 11:32:22 +0500 Subject: [PATCH 05/22] Fault Management API added --- .../SOL009-NFVMANOFaultManagement-API.json | 8388 +++++++++++ .../SOL009-NFVMANOFaultManagement-API.yaml | 12122 ++++++++++++++++ 2 files changed, 20510 insertions(+) create mode 100644 SOL009/NFVMANOFaultManagement-API/SOL009-NFVMANOFaultManagement-API.json create mode 100644 SOL009/NFVMANOFaultManagement-API/SOL009-NFVMANOFaultManagement-API.yaml diff --git a/SOL009/NFVMANOFaultManagement-API/SOL009-NFVMANOFaultManagement-API.json b/SOL009/NFVMANOFaultManagement-API/SOL009-NFVMANOFaultManagement-API.json new file mode 100644 index 000000000..cc8839c02 --- /dev/null +++ b/SOL009/NFVMANOFaultManagement-API/SOL009-NFVMANOFaultManagement-API.json @@ -0,0 +1,8388 @@ +{ + "openapi": "3.0.2", + "info": { + "version": "1.0.0-impl:etsi.org:ETSI_NFV_OpenAPI:1", + "title": "SOL009 - NFV-MANO Fault Management interface", + "description": "SOL009 - NFV-MANO Fault Management interface\nIMPORTANT: Please note that this file might be not aligned to the current version of the ETSI Group Specification it refers to. In case of discrepancies the published ETSI Group Specification takes precedence.\nPlease report bugs to https://forge.etsi.org/bugzilla/buglist.cgi?component=Nfv-Openapis&list_id=61&product=NFV&resolution=\n", + "license": { + "name": "ETSI Forge copyright notice", + "url": "https://forge.etsi.org/etsi-forge-copyright-notice.txt" + } + }, + "externalDocs": { + "description": "ETSI GS NFV-SOL 009 V3.3.1", + "url": "https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/009/03.03.01_60/gs_NFV-SOL009v030301p.pdf" + }, + "servers": [ + { + "url": "http://127.0.0.1/nfvmanofm/v1" + }, + { + "url": "https://127.0.0.1/nfvmanofm/v1" + } + ], + "paths": { + "/api_versions": { + "parameters": [ + { + "name": "Version", + "description": "Version of the API requested to use when responding to this request.\n", + "in": "header", + "required": false, + "schema": { + "type": "string" + } + }, + { + "name": "Authorization", + "description": "The authorization token for the request. Reference: IETF RFC 7235", + "in": "header", + "required": false, + "schema": { + "type": "string" + } + } + ], + "get": { + "summary": "Retrieve API version information", + "description": "The GET method reads API version information. This method shall follow the provisions specified in table 4.6.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n", + "responses": { + "200": { + "description": "200 OK\nAPI version information was read successfully. The response body shall contain 4.4 API version information, as defined in clause 4.4.1.13.\n", + "content": { + "application/json": { + "schema": { + "description": "This type represents API version information.\n", + "type": "object", + "required": [ + "uriPrefix", + "apiVersions" + ], + "properties": { + "uriPrefix": { + "description": "Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.\n", + "type": "string" + }, + "apiVersions": { + "description": "Version(s) supported for the API signaled by the uriPrefix attribute.\n", + "type": "array", + "items": { + "type": "object", + "required": [ + "version" + ], + "properties": { + "version": { + "description": "Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).\n", + "type": "string" + }, + "isDeprecated": { + "description": "If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).\nA deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.\n", + "type": "boolean" + }, + "retirementDate": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + } + } + } + } + } + } + } + }, + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "The used API version.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + } + }, + "400": { + "description": "400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\nIf the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "401": { + "description": "401 UNAUTHORIZED\nIf the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "403": { + "description": "403 FORBIDDEN\nIf the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided. It should include in the \"detail\" attribute information about the source of the problem, and may indicate how to solve it.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "404": { + "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "405": { + "description": "405 METHOD NOT ALLOWED\nIf a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "406": { + "description": "406 NOT ACCEPTABLE\nIf the \"Accept\" 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.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "413": { + "description": "413 PAYLOAD TOO LARGE\nIf the payload body of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "414": { + "description": "414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "416": { + "description": "416 Range Not Satisfiable\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "422": { + "description": "422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nThis error response code is only applicable for methods that have a request body.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "429": { + "description": "429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "500": { + "description": "500 INTERNAL SERVER ERROR\nIf there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "503": { + "description": "503 SERVICE UNAVAILABLE\nIf the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "504": { + "description": "504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + } + } + } + }, + "/alarms": { + "get": { + "description": "Get Alarm List. The client can use this method to retrieve information about the alarm list. This method shall follow the provisions specified in the tables 7.5.3.3.2-1 and 7.5.3.3.2-2 for URI query parameters, request and response data structures, and response codes.\n", + "parameters": [ + { + "name": "Version", + "description": "Version of the API requested to use when responding to this request.\n", + "in": "header", + "required": true, + "schema": { + "type": "string" + } + }, + { + "name": "Accept", + "description": "Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n", + "in": "header", + "required": true, + "schema": { + "type": "string" + } + }, + { + "name": "Authorization", + "description": "The authorization token for the request. Reference: IETF RFC 7235.\n", + "in": "header", + "required": false, + "schema": { + "type": "string" + } + }, + { + "name": "filter", + "description": "Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013. The NFV-MANO functional entity shall support receiving this parameter as part of the URI query string. The API consumer may supply this parameter. All attribute names that appear in the FmSubscription and in data types referenced from it shall be supported by the NFV-MANO functional entity in the filter expression.\n", + "in": "query", + "required": false, + "schema": { + "type": "string" + } + }, + { + "name": "nextpage_opaque_marker", + "description": "Marker to obtain the next page of a paged response. Shall be supported by the NFV-MANO functional entity if the entity supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource.\n", + "in": "query", + "required": false, + "schema": { + "type": "string" + } + } + ], + "responses": { + "200": { + "description": "200 OK\nShall be returned when information about zero or more alarms has been queried successfully. The response body shall contain in an array the representations of zero or more alarms as defined in clause 7.6.2.4. If the \"filter\" URI parameter was supplied in the request, the data in the response body shall have been transformed according to the rules specified in clause 5.2.2 of ETSI GS NFV-SOL 013. If the NFV-MANO functional entity supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource, inclusion of the Link HTTP header in this response shall follow the provisions in clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n", + "schema": { + "type": "string", + "minimum": 1, + "maximum": 1 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "minimum": 1, + "maximum": 1 + } + }, + "Link": { + "description": "Reference to other resources. Used for paging in the present document.\n", + "schema": { + "type": "string", + "minimum": 0, + "maximum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "type": "array", + "items": { + "description": "The alarm data type encapsulates information about an alarm.\n", + "type": "object", + "required": [ + "id", + "managedObjectId", + "alarmRaisedTime", + "ackState", + "perceivedSeverity", + "eventTime", + "eventType", + "probableCause", + "isRootCause", + "_links" + ], + "properties": { + "id": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "managedObjectId": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "associatedFaultyInstanceId": { + "description": "This type represents the identifier to reference a managed object of a particular type. \n", + "type": "object", + "properties": { + "type": { + "description": "Indicates the type of managed object. Permitted values:\n - MANO_ENTITY\n - MANO_SERVICE\n - MANO_SERVICE_IF\n - CONSUMED_MANO_IF\n - MANO_ENTITY_COMPONENT\n\nThe \"MANO_ENTITY COMPONENT\" is only applicable if attribute \"manoEntityComponents\" in \"ManoEntity\" is supported by the API producer.\n", + "type": "string", + "enum": [ + "MANO_ENTITY", + "MANO_SERVICE", + "MANO_SERVICE_IF", + "CONSUMED_MANO_IF", + "MANO_ENTITY_COMPONENT" + ] + }, + "objectId": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "subObjectId": { + "description": "An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n", + "type": "string" + } + }, + "required": [ + "type", + "objectId" + ] + }, + "alarmRaisedTime": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "alarmChangedTime": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "alarmClearedTime": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "ackState": { + "description": "Acknowledgement state of the alarm. Permitted values: * UNACKNOWLEDGED * ACKNOWLEDGED.\n", + "type": "string", + "enum": [ + "UNACKNOWLEDGED", + "ACKNOWLEDGED" + ] + }, + "perceivedSeverity": { + "description": "Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service\n affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting\n condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a\n non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a\n potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the\n severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or\n more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "CRITICAL", + "MAJOR", + "MINOR", + "WARNING", + "INDETERMINATE", + "CLEARED" + ] + }, + "eventTime": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "eventType": { + "description": "The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the\n procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a\n software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a\n condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the\n quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment\n fault (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "COMMUNICATIONS_ALARM", + "PROCESSING_ERROR_ALARM", + "ENVIRONMENTAL_ALARM", + "QOS_ALARM", + "EQUIPMENT_ALARM" + ] + }, + "faultType": { + "description": "Additional information to clarify the type of the fault.\n", + "type": "string" + }, + "probableCause": { + "description": "Information about the probable cause of the fault.\n", + "type": "string" + }, + "isRootCause": { + "description": "Attribute indicating if this fault is the root for other correlated alarms. If true, then the alarms listed in the attribute CorrelatedAlarmId are caused by this fault.\n", + "type": "boolean" + }, + "correlatedAlarmIds": { + "description": "List of identifiers of other alarms correlated to this fault.\n", + "type": "array", + "items": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + } + }, + "faultDetails": { + "description": "Provides additional information about the fault.\n", + "type": "array", + "items": { + "type": "string" + } + }, + "_links": { + "description": "Links for this resource.\n", + "type": "object", + "required": [ + "self" + ], + "properties": { + "self": { + "description": "This type represents a link to a resource using an absolute URI.\n", + "type": "object", + "required": [ + "href" + ], + "properties": { + "href": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + } + } + }, + "objectInstance": { + "description": "This type represents a link to a resource using an absolute URI.\n", + "type": "object", + "required": [ + "href" + ], + "properties": { + "href": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + } + } + } + } + } + } + } + } + } + } + }, + "400": { + "description": "400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\nIf the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "401": { + "description": "401 UNAUTHORIZED\nIf the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "403": { + "description": "403 FORBIDDEN\nIf the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided. It should include in the \"detail\" attribute information about the source of the problem, and may indicate how to solve it.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "404": { + "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "405": { + "description": "405 METHOD NOT ALLOWED\nIf a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "406": { + "description": "406 NOT ACCEPTABLE\nIf the \"Accept\" 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.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "422": { + "description": "422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nThis error response code is only applicable for methods that have a request body.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "500": { + "description": "500 INTERNAL SERVER ERROR\nIf there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "503": { + "description": "503 SERVICE UNAVAILABLE\nIf the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "504": { + "description": "504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + } + } + } + }, + "/alarms/{alarmId}": { + "parameters": [ + { + "name": "alarmId", + "description": "Identifier of the alarm. This identifier can be retrieved from the \"id\" attribute of the \"alarm\" attribute in the AlarmNotification or AlarmClearedNotification. It can also be retrieved from the \"id\" attribute of the applicable array element in the payload body of the response to a GET request to the \"Alarms\" resource.\n", + "in": "path", + "required": true, + "schema": { + "type": "string" + } + } + ], + "get": { + "description": "The client can use this method to read an individual alarm. This method shall follow the provisions specified in the tables 7.5.4.3.2-1 and 7.5.4.3.2-2 for URI query parameters, request and response data structures, and response codes.\n", + "parameters": [ + { + "name": "Version", + "description": "Version of the API requested to use when responding to this request.\n", + "in": "header", + "required": true, + "schema": { + "type": "string" + } + }, + { + "name": "Accept", + "description": "Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n", + "in": "header", + "required": true, + "schema": { + "type": "string" + } + }, + { + "name": "Authorization", + "description": "The authorization token for the request. Reference: IETF RFC 7235.\n", + "in": "header", + "required": false, + "schema": { + "type": "string" + } + } + ], + "responses": { + "200": { + "description": "200 OK\nShall be returned when information about an individual alarm has been read successfully. The response body shall contain a representation of the individual alarm\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n", + "schema": { + "type": "string", + "minimum": 1, + "maximum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The alarm data type encapsulates information about an alarm.\n", + "type": "object", + "required": [ + "id", + "managedObjectId", + "alarmRaisedTime", + "ackState", + "perceivedSeverity", + "eventTime", + "eventType", + "probableCause", + "isRootCause", + "_links" + ], + "properties": { + "id": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "managedObjectId": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "associatedFaultyInstanceId": { + "description": "This type represents the identifier to reference a managed object of a particular type. \n", + "type": "object", + "properties": { + "type": { + "description": "Indicates the type of managed object. Permitted values:\n - MANO_ENTITY\n - MANO_SERVICE\n - MANO_SERVICE_IF\n - CONSUMED_MANO_IF\n - MANO_ENTITY_COMPONENT\n\nThe \"MANO_ENTITY COMPONENT\" is only applicable if attribute \"manoEntityComponents\" in \"ManoEntity\" is supported by the API producer.\n", + "type": "string", + "enum": [ + "MANO_ENTITY", + "MANO_SERVICE", + "MANO_SERVICE_IF", + "CONSUMED_MANO_IF", + "MANO_ENTITY_COMPONENT" + ] + }, + "objectId": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "subObjectId": { + "description": "An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n", + "type": "string" + } + }, + "required": [ + "type", + "objectId" + ] + }, + "alarmRaisedTime": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "alarmChangedTime": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "alarmClearedTime": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "ackState": { + "description": "Acknowledgement state of the alarm. Permitted values: * UNACKNOWLEDGED * ACKNOWLEDGED.\n", + "type": "string", + "enum": [ + "UNACKNOWLEDGED", + "ACKNOWLEDGED" + ] + }, + "perceivedSeverity": { + "description": "Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service\n affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting\n condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a\n non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a\n potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the\n severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or\n more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "CRITICAL", + "MAJOR", + "MINOR", + "WARNING", + "INDETERMINATE", + "CLEARED" + ] + }, + "eventTime": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "eventType": { + "description": "The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the\n procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a\n software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a\n condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the\n quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment\n fault (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "COMMUNICATIONS_ALARM", + "PROCESSING_ERROR_ALARM", + "ENVIRONMENTAL_ALARM", + "QOS_ALARM", + "EQUIPMENT_ALARM" + ] + }, + "faultType": { + "description": "Additional information to clarify the type of the fault.\n", + "type": "string" + }, + "probableCause": { + "description": "Information about the probable cause of the fault.\n", + "type": "string" + }, + "isRootCause": { + "description": "Attribute indicating if this fault is the root for other correlated alarms. If true, then the alarms listed in the attribute CorrelatedAlarmId are caused by this fault.\n", + "type": "boolean" + }, + "correlatedAlarmIds": { + "description": "List of identifiers of other alarms correlated to this fault.\n", + "type": "array", + "items": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + } + }, + "faultDetails": { + "description": "Provides additional information about the fault.\n", + "type": "array", + "items": { + "type": "string" + } + }, + "_links": { + "description": "Links for this resource.\n", + "type": "object", + "required": [ + "self" + ], + "properties": { + "self": { + "description": "This type represents a link to a resource using an absolute URI.\n", + "type": "object", + "required": [ + "href" + ], + "properties": { + "href": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + } + } + }, + "objectInstance": { + "description": "This type represents a link to a resource using an absolute URI.\n", + "type": "object", + "required": [ + "href" + ], + "properties": { + "href": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + } + } + } + } + } + } + } + } + } + }, + "400": { + "description": "400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\nIf the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "401": { + "description": "401 UNAUTHORIZED\nIf the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "403": { + "description": "403 FORBIDDEN\nIf the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided. It should include in the \"detail\" attribute information about the source of the problem, and may indicate how to solve it.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "404": { + "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "405": { + "description": "405 METHOD NOT ALLOWED\nIf a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "406": { + "description": "406 NOT ACCEPTABLE\nIf the \"Accept\" 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.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "422": { + "description": "422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nThis error response code is only applicable for methods that have a request body.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "500": { + "description": "500 INTERNAL SERVER ERROR\nIf there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "503": { + "description": "503 SERVICE UNAVAILABLE\nIf the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "504": { + "description": "504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + } + } + }, + "patch": { + "description": "This method modifies an \"Individual alarm\" resource. This method shall follow the provisions specified in the tables 7.5.4.3.4-1 and 7.5.4.3.4-2 for URI query parameters, request and response data structures, and response codes.\n", + "parameters": [ + { + "name": "Version", + "description": "Version of the API requested to use when responding to this request.\n", + "in": "header", + "required": true, + "schema": { + "type": "string" + } + }, + { + "name": "Accept", + "description": "Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n", + "in": "header", + "required": true, + "schema": { + "type": "string" + } + }, + { + "name": "Authorization", + "description": "The authorization token for the request. Reference: IETF RFC 7235.\n", + "in": "header", + "required": false, + "schema": { + "type": "string" + } + }, + { + "name": "Content-Type", + "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n", + "in": "header", + "required": true, + "schema": { + "type": "string" + } + } + ], + "requestBody": { + "description": "The parameter for the alarm modification, as defined in clause 7.6.2.8. The Content-Type header shall be set to \"application/merge-patch+json\" according to IETF RFC 7396.\n", + "content": { + "application/json": { + "schema": { + "description": "This type represents attribute modifications for an \"Individual alarm\" resource, i.e. modifications to a resource representation based on the \"Alarm\" data type. The attributes of \"Alarm\" that can be modified are included in the \"AlarmModifications\" data type.\n", + "type": "object", + "required": [ + "ackState" + ], + "properties": { + "ackState": { + "description": "New value of the \"ackState\" attribute in \"Alarm\". Permitted values: * ACKNOWLEDGED\n", + "type": "string", + "enum": [ + "ACKNOWLEDGED" + ] + } + } + } + } + }, + "required": true + }, + "responses": { + "200": { + "description": "200 OK\nShall be returned when the request has been accepted and completed. ì The response body shall contain attribute modifications for an \"Individual alarm\" resource (see clause 7.6.2.4).\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n", + "schema": { + "type": "string", + "minimum": 1, + "maximum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "minimum": 0, + "maximum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "This type represents attribute modifications for an \"Individual alarm\" resource, i.e. modifications to a resource representation based on the \"Alarm\" data type. The attributes of \"Alarm\" that can be modified are included in the \"AlarmModifications\" data type.\n", + "type": "object", + "required": [ + "ackState" + ], + "properties": { + "ackState": { + "description": "New value of the \"ackState\" attribute in \"Alarm\". Permitted values: * ACKNOWLEDGED\n", + "type": "string", + "enum": [ + "ACKNOWLEDGED" + ] + } + } + } + } + } + }, + "400": { + "description": "400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\nIf the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "401": { + "description": "401 UNAUTHORIZED\nIf the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "403": { + "description": "403 FORBIDDEN\nIf the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided. It should include in the \"detail\" attribute information about the source of the problem, and may indicate how to solve it.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "404": { + "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "405": { + "description": "405 METHOD NOT ALLOWED\nIf a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "406": { + "description": "406 NOT ACCEPTABLE\nIf the \"Accept\" 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.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "409": { + "description": "409 CONFLICT\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "412": { + "description": "412 PRECONDITION FAILED\nError: A precondition given in an HTTP request header is not fulfilled. Typically, this is due to an ETag mismatch, indicating that the resource was modified by another entity. The response body should contain a ProblemDetails structure, in which the \"detail\" attribute should convey more information about the error.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "422": { + "description": "422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nThis error response code is only applicable for methods that have a request body.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "500": { + "description": "500 INTERNAL SERVER ERROR\nIf there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "503": { + "description": "503 SERVICE UNAVAILABLE\nIf the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "504": { + "description": "504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + } + } + } + }, + "/subscriptions": { + "post": { + "description": "Subscribe. The POST method creates a new subscription. This method shall follow the provisions specified in the tables 7.5.5.3.1-1 and 7.5.5.3.1-2 for URI query parameters, request and response data structures, and response codes. As the result of successfully executing this method, a new \"Individual subscription\" resource as defined in clause 7.5.6 shall have been created. This method shall not trigger any notification. Creation of two \"Individual subscription\" resources with the same callbackURI and the same filter can result in performance degradation and will provide duplicates of notifications to the API consumer, and might make sense only in very rare use cases. Consequently, the NFV-MANO functional entity may either allow creating a new \"Individual subscription\" resource if another \"Individual 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 \"Individual subscription\" resource (in which case it shall return a \"303 See Other\" response code referencing the existing \"Individual subscription\" resource with the same filter and callbackUri).\n", + "parameters": [ + { + "name": "Version", + "description": "Version of the API requested to use when responding to this request.\n", + "in": "header", + "required": true, + "schema": { + "type": "string" + } + }, + { + "name": "Accept", + "description": "Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n", + "in": "header", + "required": true, + "schema": { + "type": "string" + } + }, + { + "name": "Authorization", + "description": "The authorization token for the request. Reference: IETF RFC 7235.\n", + "in": "header", + "required": false, + "schema": { + "type": "string" + } + }, + { + "name": "Content-Type", + "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n", + "in": "header", + "required": true, + "schema": { + "type": "string" + } + } + ], + "requestBody": { + "description": "Details of the subscription to be created, as defined in clause 7.6.2.2.\n", + "content": { + "application/json": { + "schema": { + "description": "This type represents a subscription request related to notifications about NFV-MANO faults.\n", + "type": "object", + "required": [ + "callbackUri" + ], + "properties": { + "filter": { + "description": "This type represents a subscription filter related to notifications about NFV-MANO functional entity faults. It shall comply with the provisions defined in table 7.6.3.2-1. At a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\n", + "type": "object", + "properties": { + "notificationTypes": { + "description": "Match particular notification types. Permitted values: * AlarmNotification * AlarmClearedNotification * AlarmListRebuiltNotification The permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the notification types to facilitate automated code generation systems.\n", + "type": "array", + "items": { + "type": "string", + "enum": [ + "AlarmNotification", + "AlarmClearedNotification", + "AlarmListRebuiltNotification" + ] + } + }, + "perceivedSeverities": { + "description": "Match VNF alarms with a perceived severity listed in this attribute.\n", + "type": "array", + "items": { + "description": "Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service\n affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting\n condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a\n non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a\n potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the\n severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or\n more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "CRITICAL", + "MAJOR", + "MINOR", + "WARNING", + "INDETERMINATE", + "CLEARED" + ] + } + }, + "eventTypes": { + "description": "Match VNF alarms with an event type listed in this attribute.\n", + "type": "array", + "items": { + "description": "The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the\n procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a\n software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a\n condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the\n quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment\n fault (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "COMMUNICATIONS_ALARM", + "PROCESSING_ERROR_ALARM", + "ENVIRONMENTAL_ALARM", + "QOS_ALARM", + "EQUIPMENT_ALARM" + ] + } + }, + "probableCauses": { + "description": "Match VNF alarms with a probable cause listed in this attribute.\n", + "type": "array", + "items": { + "type": "string" + } + } + } + }, + "callbackUri": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + }, + "authentication": { + "type": "object", + "required": [ + "authType" + ], + "properties": { + "authType": { + "description": "Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values: * BASIC: In every HTTP request to the notification endpoint, use\n HTTP Basic authentication with the client credentials.\n* OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the\n notification endpoint, use an OAuth 2.0 Bearer token, obtained\n using the client credentials grant type.\n* TLS_CERT: Every HTTP request to the notification endpoint is sent\n over a mutually authenticated TLS session, i.e. not only the\n server is authenticated, but also the client is authenticated\n during the TLS tunnel setup.\n", + "type": "array", + "items": { + "type": "string", + "enum": [ + "BASIC", + "OAUTH2_CLIENT_CREDENTIALS", + "TLS_CERT" + ] + } + }, + "paramsBasic": { + "description": "Parameters for authentication/authorization using BASIC. Shall be present if authType is \"BASIC\" and the contained information has not been provisioned out of band. Shall be absent otherwise.\n", + "type": "object", + "properties": { + "userName": { + "description": "Username to be used in HTTP Basic authentication. Shall be present if it has not been provisioned out of band.\n", + "type": "string" + }, + "password": { + "description": "Password to be used in HTTP Basic authentication. Shall be present if it has not been provisioned out of band.\n", + "type": "string" + } + } + }, + "paramsOauth2ClientCredentials": { + "description": "Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS. Shall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band. Shall be absent otherwise.\n", + "type": "object", + "properties": { + "clientId": { + "description": "Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between subscriptions. The value of clientPassword should be generated by a random process.\n", + "type": "string" + }, + "clientPassword": { + "description": "Client password to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between subscriptions. The value of clientPassword should be generated by a random process.\n", + "type": "string" + }, + "tokenEndpoint": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + } + } + } + } + } + } + } + } + }, + "required": true + }, + "responses": { + "201": { + "description": "201 CREATED\nShall be returned when the subscription has been created successfully. The response body shall contain a representation of the created \"Individual subscription\" resource. The HTTP response shall include a \"Location:\"\" HTTP header that points to the created \"Individual subscription\" resource.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n", + "schema": { + "type": "string", + "minimum": 1, + "maximum": 1 + } + }, + "Location": { + "description": "The resource URI of the created subscription resource.\n", + "schema": { + "type": "string", + "format": "url", + "minimum": 1, + "maximum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "minimum": 0, + "maximum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "This type represents a subscription related to notifications about VNF faults.\n", + "type": "object", + "required": [ + "id", + "callbackUri", + "_links" + ], + "properties": { + "id": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "filter": { + "description": "This type represents a subscription filter related to notifications about NFV-MANO functional entity faults. It shall comply with the provisions defined in table 7.6.3.2-1. At a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\n", + "type": "object", + "properties": { + "notificationTypes": { + "description": "Match particular notification types. Permitted values: * AlarmNotification * AlarmClearedNotification * AlarmListRebuiltNotification The permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the notification types to facilitate automated code generation systems.\n", + "type": "array", + "items": { + "type": "string", + "enum": [ + "AlarmNotification", + "AlarmClearedNotification", + "AlarmListRebuiltNotification" + ] + } + }, + "perceivedSeverities": { + "description": "Match VNF alarms with a perceived severity listed in this attribute.\n", + "type": "array", + "items": { + "description": "Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service\n affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting\n condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a\n non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a\n potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the\n severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or\n more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "CRITICAL", + "MAJOR", + "MINOR", + "WARNING", + "INDETERMINATE", + "CLEARED" + ] + } + }, + "eventTypes": { + "description": "Match VNF alarms with an event type listed in this attribute.\n", + "type": "array", + "items": { + "description": "The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the\n procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a\n software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a\n condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the\n quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment\n fault (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "COMMUNICATIONS_ALARM", + "PROCESSING_ERROR_ALARM", + "ENVIRONMENTAL_ALARM", + "QOS_ALARM", + "EQUIPMENT_ALARM" + ] + } + }, + "probableCauses": { + "description": "Match VNF alarms with a probable cause listed in this attribute.\n", + "type": "array", + "items": { + "type": "string" + } + } + } + }, + "callbackUri": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + }, + "_links": { + "description": "Links for this resource.\n", + "type": "object", + "required": [ + "self" + ], + "properties": { + "self": { + "description": "This type represents a link to a resource using an absolute URI.\n", + "type": "object", + "required": [ + "href" + ], + "properties": { + "href": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + } + } + } + } + } + } + } + } + } + }, + "303": { + "description": "303 See Other\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + } + }, + "400": { + "description": "400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\nIf the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "401": { + "description": "401 UNAUTHORIZED\nIf the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "403": { + "description": "403 FORBIDDEN\nIf the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided. It should include in the \"detail\" attribute information about the source of the problem, and may indicate how to solve it.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "404": { + "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "405": { + "description": "405 METHOD NOT ALLOWED\nIf a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "406": { + "description": "406 NOT ACCEPTABLE\nIf the \"Accept\" 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.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "422": { + "description": "422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nThis error response code is only applicable for methods that have a request body.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "500": { + "description": "500 INTERNAL SERVER ERROR\nIf there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "503": { + "description": "503 SERVICE UNAVAILABLE\nIf the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "504": { + "description": "504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + } + } + }, + "get": { + "description": "Query Subscription Information\nThe client can use this method to retrieve the list of active subscriptions for NFV-MANO functional entity alarms subscribed by the client. It can be used e.g. for resynchronization after error situations. This method shall follow the provisions specified in the tables 7.5.5.3.2-1 and 7.5.5.3.2-2 for URI query parameters, request and response data structures, and response codes.\n", + "parameters": [ + { + "name": "Version", + "description": "Version of the API requested to use when responding to this request.\n", + "in": "header", + "required": true, + "schema": { + "type": "string" + } + }, + { + "name": "Accept", + "description": "Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n", + "in": "header", + "required": true, + "schema": { + "type": "string" + } + }, + { + "name": "Authorization", + "description": "The authorization token for the request. Reference: IETF RFC 7235.\n", + "in": "header", + "required": false, + "schema": { + "type": "string" + } + }, + { + "name": "filter", + "description": "Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013. The NFV-MANO functional entity shall support receiving this parameter as part of the URI query string. The API consumer may supply this parameter. All attribute names that appear in the FmSubscription and in data types referenced from it shall be supported by the NFV-MANO functional entity in the filter expression.\n", + "in": "query", + "required": false, + "schema": { + "type": "string" + } + }, + { + "name": "nextpage_opaque_marker", + "description": "Marker to obtain the next page of a paged response. Shall be supported by the NFV-MANO functional entity if the entity supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource.\n", + "in": "query", + "required": false, + "schema": { + "type": "string" + } + } + ], + "responses": { + "200": { + "description": "200 OK\nShall be returned when the list of subscriptions has been queried successfully. The response body shall contain in an array the representations of all active subscriptions of the functional block that invokes the method, i.e. zero or more representations of FM subscriptions as defined in clause 7.6.2.3. If the \"filter\" URI parameter was supplied in the request, the data in the response body shall have been transformed according to the rules specified in clause 5.2.2 of ETSI GS NFV-SOL 013. If the NFV-MANO functional entity supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource, inclusion of the Link HTTP header in this response shall follow the provisions in clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n", + "schema": { + "type": "string", + "minimum": 1, + "maximum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "minimum": 0, + "maximum": 1 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "minimum": 1, + "maximum": 1 + } + }, + "Link": { + "description": "Reference to other resources. Used for paging in the present document, see clause 4.7.2.1.\n", + "schema": { + "type": "string", + "minimum": 0, + "maximum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "type": "array", + "items": { + "description": "This type represents a subscription related to notifications about VNF faults.\n", + "type": "object", + "required": [ + "id", + "callbackUri", + "_links" + ], + "properties": { + "id": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "filter": { + "description": "This type represents a subscription filter related to notifications about NFV-MANO functional entity faults. It shall comply with the provisions defined in table 7.6.3.2-1. At a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\n", + "type": "object", + "properties": { + "notificationTypes": { + "description": "Match particular notification types. Permitted values: * AlarmNotification * AlarmClearedNotification * AlarmListRebuiltNotification The permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the notification types to facilitate automated code generation systems.\n", + "type": "array", + "items": { + "type": "string", + "enum": [ + "AlarmNotification", + "AlarmClearedNotification", + "AlarmListRebuiltNotification" + ] + } + }, + "perceivedSeverities": { + "description": "Match VNF alarms with a perceived severity listed in this attribute.\n", + "type": "array", + "items": { + "description": "Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service\n affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting\n condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a\n non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a\n potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the\n severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or\n more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "CRITICAL", + "MAJOR", + "MINOR", + "WARNING", + "INDETERMINATE", + "CLEARED" + ] + } + }, + "eventTypes": { + "description": "Match VNF alarms with an event type listed in this attribute.\n", + "type": "array", + "items": { + "description": "The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the\n procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a\n software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a\n condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the\n quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment\n fault (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "COMMUNICATIONS_ALARM", + "PROCESSING_ERROR_ALARM", + "ENVIRONMENTAL_ALARM", + "QOS_ALARM", + "EQUIPMENT_ALARM" + ] + } + }, + "probableCauses": { + "description": "Match VNF alarms with a probable cause listed in this attribute.\n", + "type": "array", + "items": { + "type": "string" + } + } + } + }, + "callbackUri": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + }, + "_links": { + "description": "Links for this resource.\n", + "type": "object", + "required": [ + "self" + ], + "properties": { + "self": { + "description": "This type represents a link to a resource using an absolute URI.\n", + "type": "object", + "required": [ + "href" + ], + "properties": { + "href": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + } + } + } + } + } + } + } + } + } + } + }, + "400": { + "description": "400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\nIf the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "401": { + "description": "401 UNAUTHORIZED\nIf the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "403": { + "description": "403 FORBIDDEN\nIf the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided. It should include in the \"detail\" attribute information about the source of the problem, and may indicate how to solve it.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "404": { + "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "405": { + "description": "405 METHOD NOT ALLOWED\nIf a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "406": { + "description": "406 NOT ACCEPTABLE\nIf the \"Accept\" 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.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "422": { + "description": "422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nThis error response code is only applicable for methods that have a request body.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "500": { + "description": "500 INTERNAL SERVER ERROR\nIf there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "503": { + "description": "503 SERVICE UNAVAILABLE\nIf the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "504": { + "description": "504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + } + } + } + }, + "/subscriptions/{subscriptionId}": { + "parameters": [ + { + "name": "subscriptionId", + "description": "Identifier of this subscription. This identifier can be retrieved from the resource referenced by the \"Location\" HTTP header in the response to a POST request creating a new \"Individual subscription\" resource. It can also be retrieved from the \"id\" attribute in the payload body of that response.\n", + "in": "path", + "required": true, + "schema": { + "type": "string" + } + } + ], + "get": { + "description": "Query Subscription Information. The client can use this method for reading an individual subscription for NFV-MANO functional entity alarms subscribed by the client. This method shall follow the provisions specified in the tables 7.5.6.3.2-1 and 7.5.6.3.2-2 for URI query parameters, request and response data structures, and response codes.\n", + "parameters": [ + { + "name": "Version", + "description": "Version of the API requested to use when responding to this request.\n", + "in": "header", + "required": true, + "schema": { + "type": "string" + } + }, + { + "name": "Accept", + "description": "Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n", + "in": "header", + "required": true, + "schema": { + "type": "string" + } + }, + { + "name": "Authorization", + "description": "The authorization token for the request. Reference: IETF RFC 7235.\n", + "in": "header", + "required": false, + "schema": { + "type": "string" + } + } + ], + "responses": { + "200": { + "description": "200 OK\nThe operation has completed successfully. The response body shall contain a representation of the subscription resource.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n", + "schema": { + "type": "string", + "minimum": 1, + "maximum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "minimum": 0, + "maximum": 1 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "minimum": 1, + "maximum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "This type represents a subscription related to notifications about VNF faults.\n", + "type": "object", + "required": [ + "id", + "callbackUri", + "_links" + ], + "properties": { + "id": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "filter": { + "description": "This type represents a subscription filter related to notifications about NFV-MANO functional entity faults. It shall comply with the provisions defined in table 7.6.3.2-1. At a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\n", + "type": "object", + "properties": { + "notificationTypes": { + "description": "Match particular notification types. Permitted values: * AlarmNotification * AlarmClearedNotification * AlarmListRebuiltNotification The permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the notification types to facilitate automated code generation systems.\n", + "type": "array", + "items": { + "type": "string", + "enum": [ + "AlarmNotification", + "AlarmClearedNotification", + "AlarmListRebuiltNotification" + ] + } + }, + "perceivedSeverities": { + "description": "Match VNF alarms with a perceived severity listed in this attribute.\n", + "type": "array", + "items": { + "description": "Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service\n affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting\n condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a\n non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a\n potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the\n severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or\n more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "CRITICAL", + "MAJOR", + "MINOR", + "WARNING", + "INDETERMINATE", + "CLEARED" + ] + } + }, + "eventTypes": { + "description": "Match VNF alarms with an event type listed in this attribute.\n", + "type": "array", + "items": { + "description": "The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the\n procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a\n software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a\n condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the\n quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment\n fault (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "COMMUNICATIONS_ALARM", + "PROCESSING_ERROR_ALARM", + "ENVIRONMENTAL_ALARM", + "QOS_ALARM", + "EQUIPMENT_ALARM" + ] + } + }, + "probableCauses": { + "description": "Match VNF alarms with a probable cause listed in this attribute.\n", + "type": "array", + "items": { + "type": "string" + } + } + } + }, + "callbackUri": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + }, + "_links": { + "description": "Links for this resource.\n", + "type": "object", + "required": [ + "self" + ], + "properties": { + "self": { + "description": "This type represents a link to a resource using an absolute URI.\n", + "type": "object", + "required": [ + "href" + ], + "properties": { + "href": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + } + } + } + } + } + } + } + } + } + }, + "400": { + "description": "400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\nIf the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "401": { + "description": "401 UNAUTHORIZED\nIf the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "403": { + "description": "403 FORBIDDEN\nIf the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided. It should include in the \"detail\" attribute information about the source of the problem, and may indicate how to solve it.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "404": { + "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "405": { + "description": "405 METHOD NOT ALLOWED\nIf a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "406": { + "description": "406 NOT ACCEPTABLE\nIf the \"Accept\" 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.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "422": { + "description": "422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nThis error response code is only applicable for methods that have a request body.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "500": { + "description": "500 INTERNAL SERVER ERROR\nIf there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "503": { + "description": "503 SERVICE UNAVAILABLE\nIf the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "504": { + "description": "504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + } + } + }, + "delete": { + "description": "Terminate Subscription. This method terminates an individual subscription. This method shall follow the provisions specified in the tables 7.5.6.3.5-1 and 7.5.6.3.5-2 for URI query parameters, request and response data structures, and response codes. As the result of successfully executing this method, the \"Individual subscription\" resource shall not exist any longer. This means that no notifications for that subscription shall be sent to the formerly-subscribed API consumer. NOTE:\tDue to race conditions, some notifications might still be received by the formerly-subscribed API consumer for a certain time period after the deletion.\n", + "parameters": [ + { + "name": "Version", + "description": "Version of the API requested to use when responding to this request.\n", + "in": "header", + "required": true, + "schema": { + "type": "string" + } + }, + { + "name": "Authorization", + "description": "The authorization token for the request. Reference: IETF RFC 7235.\n", + "in": "header", + "required": false, + "schema": { + "type": "string" + } + } + ], + "responses": { + "204": { + "description": "204 NO CONTENT\nShall be returned when the \"Individual subscription\" resource has been deleted successfully. The response body shall be empty.\n", + "headers": { + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "minimum": 0, + "maximum": 1 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "minimum": 1, + "maximum": 1 + } + } + } + }, + "400": { + "description": "400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\nIf the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "401": { + "description": "401 UNAUTHORIZED\nIf the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "403": { + "description": "403 FORBIDDEN\nIf the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided. It should include in the \"detail\" attribute information about the source of the problem, and may indicate how to solve it.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "404": { + "description": "404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "405": { + "description": "405 METHOD NOT ALLOWED\nIf a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "406": { + "description": "406 NOT ACCEPTABLE\nIf the \"Accept\" 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.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "422": { + "description": "422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nThis error response code is only applicable for methods that have a request body.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "500": { + "description": "500 INTERNAL SERVER ERROR\nIf there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "503": { + "description": "503 SERVICE UNAVAILABLE\nIf the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + }, + "504": { + "description": "504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the response.", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 0 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "maximum": 1, + "minimum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n", + "type": "object", + "required": [ + "status", + "detail" + ], + "properties": { + "type": { + "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n", + "type": "string", + "format": "URI" + }, + "title": { + "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n", + "type": "string" + }, + "status": { + "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n", + "type": "integer" + }, + "detail": { + "description": "A human-readable explanation specific to this occurrence of the problem.\n", + "type": "string" + }, + "instance": { + "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n", + "type": "string", + "format": "URI" + } + } + } + } + } + } + } + } + } + }, + "components": { + "parameters": { + "alarmId": { + "name": "alarmId", + "description": "Identifier of the alarm. This identifier can be retrieved from the \"id\" attribute of the \"alarm\" attribute in the AlarmNotification or AlarmClearedNotification. It can also be retrieved from the \"id\" attribute of the applicable array element in the payload body of the response to a GET request to the \"Alarms\" resource.\n", + "in": "path", + "required": true, + "schema": { + "type": "string" + } + }, + "subscriptionId": { + "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 \"Individual subscription\" resource. It can also be retrieved from the \"id\" attribute in the payload body of that response.\n", + "in": "path", + "required": true, + "schema": { + "type": "string" + } + } + }, + "schemas": { + "FmSubscriptionRequest": { + "description": "This type represents a subscription request related to notifications about NFV-MANO faults.\n", + "type": "object", + "required": [ + "callbackUri" + ], + "properties": { + "filter": { + "description": "This type represents a subscription filter related to notifications about NFV-MANO functional entity faults. It shall comply with the provisions defined in table 7.6.3.2-1. At a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\n", + "type": "object", + "properties": { + "notificationTypes": { + "description": "Match particular notification types. Permitted values: * AlarmNotification * AlarmClearedNotification * AlarmListRebuiltNotification The permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the notification types to facilitate automated code generation systems.\n", + "type": "array", + "items": { + "type": "string", + "enum": [ + "AlarmNotification", + "AlarmClearedNotification", + "AlarmListRebuiltNotification" + ] + } + }, + "perceivedSeverities": { + "description": "Match VNF alarms with a perceived severity listed in this attribute.\n", + "type": "array", + "items": { + "description": "Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service\n affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting\n condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a\n non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a\n potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the\n severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or\n more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "CRITICAL", + "MAJOR", + "MINOR", + "WARNING", + "INDETERMINATE", + "CLEARED" + ] + } + }, + "eventTypes": { + "description": "Match VNF alarms with an event type listed in this attribute.\n", + "type": "array", + "items": { + "description": "The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the\n procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a\n software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a\n condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the\n quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment\n fault (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "COMMUNICATIONS_ALARM", + "PROCESSING_ERROR_ALARM", + "ENVIRONMENTAL_ALARM", + "QOS_ALARM", + "EQUIPMENT_ALARM" + ] + } + }, + "probableCauses": { + "description": "Match VNF alarms with a probable cause listed in this attribute.\n", + "type": "array", + "items": { + "type": "string" + } + } + } + }, + "callbackUri": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + }, + "authentication": { + "type": "object", + "required": [ + "authType" + ], + "properties": { + "authType": { + "description": "Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values: * BASIC: In every HTTP request to the notification endpoint, use\n HTTP Basic authentication with the client credentials.\n* OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the\n notification endpoint, use an OAuth 2.0 Bearer token, obtained\n using the client credentials grant type.\n* TLS_CERT: Every HTTP request to the notification endpoint is sent\n over a mutually authenticated TLS session, i.e. not only the\n server is authenticated, but also the client is authenticated\n during the TLS tunnel setup.\n", + "type": "array", + "items": { + "type": "string", + "enum": [ + "BASIC", + "OAUTH2_CLIENT_CREDENTIALS", + "TLS_CERT" + ] + } + }, + "paramsBasic": { + "description": "Parameters for authentication/authorization using BASIC. Shall be present if authType is \"BASIC\" and the contained information has not been provisioned out of band. Shall be absent otherwise.\n", + "type": "object", + "properties": { + "userName": { + "description": "Username to be used in HTTP Basic authentication. Shall be present if it has not been provisioned out of band.\n", + "type": "string" + }, + "password": { + "description": "Password to be used in HTTP Basic authentication. Shall be present if it has not been provisioned out of band.\n", + "type": "string" + } + } + }, + "paramsOauth2ClientCredentials": { + "description": "Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS. Shall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band. Shall be absent otherwise.\n", + "type": "object", + "properties": { + "clientId": { + "description": "Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between subscriptions. The value of clientPassword should be generated by a random process.\n", + "type": "string" + }, + "clientPassword": { + "description": "Client password to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between subscriptions. The value of clientPassword should be generated by a random process.\n", + "type": "string" + }, + "tokenEndpoint": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + } + } + } + } + } + } + }, + "FmSubscription": { + "description": "This type represents a subscription related to notifications about VNF faults.\n", + "type": "object", + "required": [ + "id", + "callbackUri", + "_links" + ], + "properties": { + "id": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "filter": { + "description": "This type represents a subscription filter related to notifications about NFV-MANO functional entity faults. It shall comply with the provisions defined in table 7.6.3.2-1. At a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\n", + "type": "object", + "properties": { + "notificationTypes": { + "description": "Match particular notification types. Permitted values: * AlarmNotification * AlarmClearedNotification * AlarmListRebuiltNotification The permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the notification types to facilitate automated code generation systems.\n", + "type": "array", + "items": { + "type": "string", + "enum": [ + "AlarmNotification", + "AlarmClearedNotification", + "AlarmListRebuiltNotification" + ] + } + }, + "perceivedSeverities": { + "description": "Match VNF alarms with a perceived severity listed in this attribute.\n", + "type": "array", + "items": { + "description": "Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service\n affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting\n condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a\n non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a\n potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the\n severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or\n more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "CRITICAL", + "MAJOR", + "MINOR", + "WARNING", + "INDETERMINATE", + "CLEARED" + ] + } + }, + "eventTypes": { + "description": "Match VNF alarms with an event type listed in this attribute.\n", + "type": "array", + "items": { + "description": "The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the\n procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a\n software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a\n condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the\n quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment\n fault (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "COMMUNICATIONS_ALARM", + "PROCESSING_ERROR_ALARM", + "ENVIRONMENTAL_ALARM", + "QOS_ALARM", + "EQUIPMENT_ALARM" + ] + } + }, + "probableCauses": { + "description": "Match VNF alarms with a probable cause listed in this attribute.\n", + "type": "array", + "items": { + "type": "string" + } + } + } + }, + "callbackUri": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + }, + "_links": { + "description": "Links for this resource.\n", + "type": "object", + "required": [ + "self" + ], + "properties": { + "self": { + "description": "This type represents a link to a resource using an absolute URI.\n", + "type": "object", + "required": [ + "href" + ], + "properties": { + "href": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + } + } + } + } + } + } + }, + "AlarmModifications": { + "description": "This type represents attribute modifications for an \"Individual alarm\" resource, i.e. modifications to a resource representation based on the \"Alarm\" data type. The attributes of \"Alarm\" that can be modified are included in the \"AlarmModifications\" data type.\n", + "type": "object", + "required": [ + "ackState" + ], + "properties": { + "ackState": { + "description": "New value of the \"ackState\" attribute in \"Alarm\". Permitted values: * ACKNOWLEDGED\n", + "type": "string", + "enum": [ + "ACKNOWLEDGED" + ] + } + } + }, + "FmNotificationsFilter": { + "description": "This type represents a subscription filter related to notifications about NFV-MANO functional entity faults. It shall comply with the provisions defined in table 7.6.3.2-1. At a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\n", + "type": "object", + "properties": { + "notificationTypes": { + "description": "Match particular notification types. Permitted values: * AlarmNotification * AlarmClearedNotification * AlarmListRebuiltNotification The permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the notification types to facilitate automated code generation systems.\n", + "type": "array", + "items": { + "type": "string", + "enum": [ + "AlarmNotification", + "AlarmClearedNotification", + "AlarmListRebuiltNotification" + ] + } + }, + "perceivedSeverities": { + "description": "Match VNF alarms with a perceived severity listed in this attribute.\n", + "type": "array", + "items": { + "description": "Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service\n affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting\n condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a\n non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a\n potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the\n severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or\n more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "CRITICAL", + "MAJOR", + "MINOR", + "WARNING", + "INDETERMINATE", + "CLEARED" + ] + } + }, + "eventTypes": { + "description": "Match VNF alarms with an event type listed in this attribute.\n", + "type": "array", + "items": { + "description": "The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the\n procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a\n software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a\n condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the\n quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment\n fault (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "COMMUNICATIONS_ALARM", + "PROCESSING_ERROR_ALARM", + "ENVIRONMENTAL_ALARM", + "QOS_ALARM", + "EQUIPMENT_ALARM" + ] + } + }, + "probableCauses": { + "description": "Match VNF alarms with a probable cause listed in this attribute.\n", + "type": "array", + "items": { + "type": "string" + } + } + } + } + }, + "requestBodies": { + "AlarmModifications": { + "description": "The parameter for the alarm modification, as defined in clause 7.6.2.8. The Content-Type header shall be set to \"application/merge-patch+json\" according to IETF RFC 7396.\n", + "content": { + "application/json": { + "schema": { + "description": "This type represents attribute modifications for an \"Individual alarm\" resource, i.e. modifications to a resource representation based on the \"Alarm\" data type. The attributes of \"Alarm\" that can be modified are included in the \"AlarmModifications\" data type.\n", + "type": "object", + "required": [ + "ackState" + ], + "properties": { + "ackState": { + "description": "New value of the \"ackState\" attribute in \"Alarm\". Permitted values: * ACKNOWLEDGED\n", + "type": "string", + "enum": [ + "ACKNOWLEDGED" + ] + } + } + } + } + }, + "required": true + }, + "FmSubscriptionRequest": { + "description": "Details of the subscription to be created, as defined in clause 7.6.2.2.\n", + "content": { + "application/json": { + "schema": { + "description": "This type represents a subscription request related to notifications about NFV-MANO faults.\n", + "type": "object", + "required": [ + "callbackUri" + ], + "properties": { + "filter": { + "description": "This type represents a subscription filter related to notifications about NFV-MANO functional entity faults. It shall comply with the provisions defined in table 7.6.3.2-1. At a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\n", + "type": "object", + "properties": { + "notificationTypes": { + "description": "Match particular notification types. Permitted values: * AlarmNotification * AlarmClearedNotification * AlarmListRebuiltNotification The permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the notification types to facilitate automated code generation systems.\n", + "type": "array", + "items": { + "type": "string", + "enum": [ + "AlarmNotification", + "AlarmClearedNotification", + "AlarmListRebuiltNotification" + ] + } + }, + "perceivedSeverities": { + "description": "Match VNF alarms with a perceived severity listed in this attribute.\n", + "type": "array", + "items": { + "description": "Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service\n affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting\n condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a\n non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a\n potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the\n severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or\n more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "CRITICAL", + "MAJOR", + "MINOR", + "WARNING", + "INDETERMINATE", + "CLEARED" + ] + } + }, + "eventTypes": { + "description": "Match VNF alarms with an event type listed in this attribute.\n", + "type": "array", + "items": { + "description": "The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the\n procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a\n software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a\n condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the\n quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment\n fault (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "COMMUNICATIONS_ALARM", + "PROCESSING_ERROR_ALARM", + "ENVIRONMENTAL_ALARM", + "QOS_ALARM", + "EQUIPMENT_ALARM" + ] + } + }, + "probableCauses": { + "description": "Match VNF alarms with a probable cause listed in this attribute.\n", + "type": "array", + "items": { + "type": "string" + } + } + } + }, + "callbackUri": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + }, + "authentication": { + "type": "object", + "required": [ + "authType" + ], + "properties": { + "authType": { + "description": "Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values: * BASIC: In every HTTP request to the notification endpoint, use\n HTTP Basic authentication with the client credentials.\n* OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the\n notification endpoint, use an OAuth 2.0 Bearer token, obtained\n using the client credentials grant type.\n* TLS_CERT: Every HTTP request to the notification endpoint is sent\n over a mutually authenticated TLS session, i.e. not only the\n server is authenticated, but also the client is authenticated\n during the TLS tunnel setup.\n", + "type": "array", + "items": { + "type": "string", + "enum": [ + "BASIC", + "OAUTH2_CLIENT_CREDENTIALS", + "TLS_CERT" + ] + } + }, + "paramsBasic": { + "description": "Parameters for authentication/authorization using BASIC. Shall be present if authType is \"BASIC\" and the contained information has not been provisioned out of band. Shall be absent otherwise.\n", + "type": "object", + "properties": { + "userName": { + "description": "Username to be used in HTTP Basic authentication. Shall be present if it has not been provisioned out of band.\n", + "type": "string" + }, + "password": { + "description": "Password to be used in HTTP Basic authentication. Shall be present if it has not been provisioned out of band.\n", + "type": "string" + } + } + }, + "paramsOauth2ClientCredentials": { + "description": "Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS. Shall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band. Shall be absent otherwise.\n", + "type": "object", + "properties": { + "clientId": { + "description": "Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between subscriptions. The value of clientPassword should be generated by a random process.\n", + "type": "string" + }, + "clientPassword": { + "description": "Client password to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between subscriptions. The value of clientPassword should be generated by a random process.\n", + "type": "string" + }, + "tokenEndpoint": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + } + } + } + } + } + } + } + } + }, + "required": true + } + }, + "responses": { + "Alarms.Get": { + "description": "200 OK\nShall be returned when information about zero or more alarms has been queried successfully. The response body shall contain in an array the representations of zero or more alarms as defined in clause 7.6.2.4. If the \"filter\" URI parameter was supplied in the request, the data in the response body shall have been transformed according to the rules specified in clause 5.2.2 of ETSI GS NFV-SOL 013. If the NFV-MANO functional entity supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource, inclusion of the Link HTTP header in this response shall follow the provisions in clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n", + "schema": { + "type": "string", + "minimum": 1, + "maximum": 1 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "minimum": 1, + "maximum": 1 + } + }, + "Link": { + "description": "Reference to other resources. Used for paging in the present document.\n", + "schema": { + "type": "string", + "minimum": 0, + "maximum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "type": "array", + "items": { + "description": "The alarm data type encapsulates information about an alarm.\n", + "type": "object", + "required": [ + "id", + "managedObjectId", + "alarmRaisedTime", + "ackState", + "perceivedSeverity", + "eventTime", + "eventType", + "probableCause", + "isRootCause", + "_links" + ], + "properties": { + "id": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "managedObjectId": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "associatedFaultyInstanceId": { + "description": "This type represents the identifier to reference a managed object of a particular type. \n", + "type": "object", + "properties": { + "type": { + "description": "Indicates the type of managed object. Permitted values:\n - MANO_ENTITY\n - MANO_SERVICE\n - MANO_SERVICE_IF\n - CONSUMED_MANO_IF\n - MANO_ENTITY_COMPONENT\n\nThe \"MANO_ENTITY COMPONENT\" is only applicable if attribute \"manoEntityComponents\" in \"ManoEntity\" is supported by the API producer.\n", + "type": "string", + "enum": [ + "MANO_ENTITY", + "MANO_SERVICE", + "MANO_SERVICE_IF", + "CONSUMED_MANO_IF", + "MANO_ENTITY_COMPONENT" + ] + }, + "objectId": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "subObjectId": { + "description": "An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n", + "type": "string" + } + }, + "required": [ + "type", + "objectId" + ] + }, + "alarmRaisedTime": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "alarmChangedTime": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "alarmClearedTime": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "ackState": { + "description": "Acknowledgement state of the alarm. Permitted values: * UNACKNOWLEDGED * ACKNOWLEDGED.\n", + "type": "string", + "enum": [ + "UNACKNOWLEDGED", + "ACKNOWLEDGED" + ] + }, + "perceivedSeverity": { + "description": "Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service\n affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting\n condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a\n non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a\n potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the\n severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or\n more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "CRITICAL", + "MAJOR", + "MINOR", + "WARNING", + "INDETERMINATE", + "CLEARED" + ] + }, + "eventTime": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "eventType": { + "description": "The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the\n procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a\n software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a\n condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the\n quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment\n fault (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "COMMUNICATIONS_ALARM", + "PROCESSING_ERROR_ALARM", + "ENVIRONMENTAL_ALARM", + "QOS_ALARM", + "EQUIPMENT_ALARM" + ] + }, + "faultType": { + "description": "Additional information to clarify the type of the fault.\n", + "type": "string" + }, + "probableCause": { + "description": "Information about the probable cause of the fault.\n", + "type": "string" + }, + "isRootCause": { + "description": "Attribute indicating if this fault is the root for other correlated alarms. If true, then the alarms listed in the attribute CorrelatedAlarmId are caused by this fault.\n", + "type": "boolean" + }, + "correlatedAlarmIds": { + "description": "List of identifiers of other alarms correlated to this fault.\n", + "type": "array", + "items": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + } + }, + "faultDetails": { + "description": "Provides additional information about the fault.\n", + "type": "array", + "items": { + "type": "string" + } + }, + "_links": { + "description": "Links for this resource.\n", + "type": "object", + "required": [ + "self" + ], + "properties": { + "self": { + "description": "This type represents a link to a resource using an absolute URI.\n", + "type": "object", + "required": [ + "href" + ], + "properties": { + "href": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + } + } + }, + "objectInstance": { + "description": "This type represents a link to a resource using an absolute URI.\n", + "type": "object", + "required": [ + "href" + ], + "properties": { + "href": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + } + } + } + } + } + } + } + } + } + } + }, + "Alarm.Get": { + "description": "200 OK\nShall be returned when information about an individual alarm has been read successfully. The response body shall contain a representation of the individual alarm\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n", + "schema": { + "type": "string", + "minimum": 1, + "maximum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "The alarm data type encapsulates information about an alarm.\n", + "type": "object", + "required": [ + "id", + "managedObjectId", + "alarmRaisedTime", + "ackState", + "perceivedSeverity", + "eventTime", + "eventType", + "probableCause", + "isRootCause", + "_links" + ], + "properties": { + "id": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "managedObjectId": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "associatedFaultyInstanceId": { + "description": "This type represents the identifier to reference a managed object of a particular type. \n", + "type": "object", + "properties": { + "type": { + "description": "Indicates the type of managed object. Permitted values:\n - MANO_ENTITY\n - MANO_SERVICE\n - MANO_SERVICE_IF\n - CONSUMED_MANO_IF\n - MANO_ENTITY_COMPONENT\n\nThe \"MANO_ENTITY COMPONENT\" is only applicable if attribute \"manoEntityComponents\" in \"ManoEntity\" is supported by the API producer.\n", + "type": "string", + "enum": [ + "MANO_ENTITY", + "MANO_SERVICE", + "MANO_SERVICE_IF", + "CONSUMED_MANO_IF", + "MANO_ENTITY_COMPONENT" + ] + }, + "objectId": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "subObjectId": { + "description": "An identifier that is unique for the respective type within a NFV-MANO functional entity, but that need not be globally unique. Representation: string of variable length..\n", + "type": "string" + } + }, + "required": [ + "type", + "objectId" + ] + }, + "alarmRaisedTime": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "alarmChangedTime": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "alarmClearedTime": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "ackState": { + "description": "Acknowledgement state of the alarm. Permitted values: * UNACKNOWLEDGED * ACKNOWLEDGED.\n", + "type": "string", + "enum": [ + "UNACKNOWLEDGED", + "ACKNOWLEDGED" + ] + }, + "perceivedSeverity": { + "description": "Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service\n affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting\n condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a\n non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a\n potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the\n severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or\n more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "CRITICAL", + "MAJOR", + "MINOR", + "WARNING", + "INDETERMINATE", + "CLEARED" + ] + }, + "eventTime": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "eventType": { + "description": "The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the\n procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a\n software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a\n condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the\n quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment\n fault (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "COMMUNICATIONS_ALARM", + "PROCESSING_ERROR_ALARM", + "ENVIRONMENTAL_ALARM", + "QOS_ALARM", + "EQUIPMENT_ALARM" + ] + }, + "faultType": { + "description": "Additional information to clarify the type of the fault.\n", + "type": "string" + }, + "probableCause": { + "description": "Information about the probable cause of the fault.\n", + "type": "string" + }, + "isRootCause": { + "description": "Attribute indicating if this fault is the root for other correlated alarms. If true, then the alarms listed in the attribute CorrelatedAlarmId are caused by this fault.\n", + "type": "boolean" + }, + "correlatedAlarmIds": { + "description": "List of identifiers of other alarms correlated to this fault.\n", + "type": "array", + "items": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + } + }, + "faultDetails": { + "description": "Provides additional information about the fault.\n", + "type": "array", + "items": { + "type": "string" + } + }, + "_links": { + "description": "Links for this resource.\n", + "type": "object", + "required": [ + "self" + ], + "properties": { + "self": { + "description": "This type represents a link to a resource using an absolute URI.\n", + "type": "object", + "required": [ + "href" + ], + "properties": { + "href": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + } + } + }, + "objectInstance": { + "description": "This type represents a link to a resource using an absolute URI.\n", + "type": "object", + "required": [ + "href" + ], + "properties": { + "href": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + } + } + } + } + } + } + } + } + } + }, + "Alarm.Patch": { + "description": "200 OK\nShall be returned when the request has been accepted and completed. ì The response body shall contain attribute modifications for an \"Individual alarm\" resource (see clause 7.6.2.4).\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n", + "schema": { + "type": "string", + "minimum": 1, + "maximum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "minimum": 0, + "maximum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "This type represents attribute modifications for an \"Individual alarm\" resource, i.e. modifications to a resource representation based on the \"Alarm\" data type. The attributes of \"Alarm\" that can be modified are included in the \"AlarmModifications\" data type.\n", + "type": "object", + "required": [ + "ackState" + ], + "properties": { + "ackState": { + "description": "New value of the \"ackState\" attribute in \"Alarm\". Permitted values: * ACKNOWLEDGED\n", + "type": "string", + "enum": [ + "ACKNOWLEDGED" + ] + } + } + } + } + } + }, + "subscriptions.post.201": { + "description": "201 CREATED\nShall be returned when the subscription has been created successfully. The response body shall contain a representation of the created \"Individual subscription\" resource. The HTTP response shall include a \"Location:\"\" HTTP header that points to the created \"Individual subscription\" resource.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n", + "schema": { + "type": "string", + "minimum": 1, + "maximum": 1 + } + }, + "Location": { + "description": "The resource URI of the created subscription resource.\n", + "schema": { + "type": "string", + "format": "url", + "minimum": 1, + "maximum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "minimum": 0, + "maximum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "This type represents a subscription related to notifications about VNF faults.\n", + "type": "object", + "required": [ + "id", + "callbackUri", + "_links" + ], + "properties": { + "id": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "filter": { + "description": "This type represents a subscription filter related to notifications about NFV-MANO functional entity faults. It shall comply with the provisions defined in table 7.6.3.2-1. At a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\n", + "type": "object", + "properties": { + "notificationTypes": { + "description": "Match particular notification types. Permitted values: * AlarmNotification * AlarmClearedNotification * AlarmListRebuiltNotification The permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the notification types to facilitate automated code generation systems.\n", + "type": "array", + "items": { + "type": "string", + "enum": [ + "AlarmNotification", + "AlarmClearedNotification", + "AlarmListRebuiltNotification" + ] + } + }, + "perceivedSeverities": { + "description": "Match VNF alarms with a perceived severity listed in this attribute.\n", + "type": "array", + "items": { + "description": "Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service\n affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting\n condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a\n non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a\n potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the\n severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or\n more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "CRITICAL", + "MAJOR", + "MINOR", + "WARNING", + "INDETERMINATE", + "CLEARED" + ] + } + }, + "eventTypes": { + "description": "Match VNF alarms with an event type listed in this attribute.\n", + "type": "array", + "items": { + "description": "The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the\n procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a\n software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a\n condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the\n quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment\n fault (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "COMMUNICATIONS_ALARM", + "PROCESSING_ERROR_ALARM", + "ENVIRONMENTAL_ALARM", + "QOS_ALARM", + "EQUIPMENT_ALARM" + ] + } + }, + "probableCauses": { + "description": "Match VNF alarms with a probable cause listed in this attribute.\n", + "type": "array", + "items": { + "type": "string" + } + } + } + }, + "callbackUri": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + }, + "_links": { + "description": "Links for this resource.\n", + "type": "object", + "required": [ + "self" + ], + "properties": { + "self": { + "description": "This type represents a link to a resource using an absolute URI.\n", + "type": "object", + "required": [ + "href" + ], + "properties": { + "href": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + } + } + } + } + } + } + } + } + } + }, + "subscriptions.get.200": { + "description": "200 OK\nShall be returned when the list of subscriptions has been queried successfully. The response body shall contain in an array the representations of all active subscriptions of the functional block that invokes the method, i.e. zero or more representations of FM subscriptions as defined in clause 7.6.2.3. If the \"filter\" URI parameter was supplied in the request, the data in the response body shall have been transformed according to the rules specified in clause 5.2.2 of ETSI GS NFV-SOL 013. If the NFV-MANO functional entity supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource, inclusion of the Link HTTP header in this response shall follow the provisions in clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n", + "schema": { + "type": "string", + "minimum": 1, + "maximum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "minimum": 0, + "maximum": 1 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "minimum": 1, + "maximum": 1 + } + }, + "Link": { + "description": "Reference to other resources. Used for paging in the present document, see clause 4.7.2.1.\n", + "schema": { + "type": "string", + "minimum": 0, + "maximum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "type": "array", + "items": { + "description": "This type represents a subscription related to notifications about VNF faults.\n", + "type": "object", + "required": [ + "id", + "callbackUri", + "_links" + ], + "properties": { + "id": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "filter": { + "description": "This type represents a subscription filter related to notifications about NFV-MANO functional entity faults. It shall comply with the provisions defined in table 7.6.3.2-1. At a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\n", + "type": "object", + "properties": { + "notificationTypes": { + "description": "Match particular notification types. Permitted values: * AlarmNotification * AlarmClearedNotification * AlarmListRebuiltNotification The permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the notification types to facilitate automated code generation systems.\n", + "type": "array", + "items": { + "type": "string", + "enum": [ + "AlarmNotification", + "AlarmClearedNotification", + "AlarmListRebuiltNotification" + ] + } + }, + "perceivedSeverities": { + "description": "Match VNF alarms with a perceived severity listed in this attribute.\n", + "type": "array", + "items": { + "description": "Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service\n affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting\n condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a\n non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a\n potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the\n severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or\n more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "CRITICAL", + "MAJOR", + "MINOR", + "WARNING", + "INDETERMINATE", + "CLEARED" + ] + } + }, + "eventTypes": { + "description": "Match VNF alarms with an event type listed in this attribute.\n", + "type": "array", + "items": { + "description": "The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the\n procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a\n software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a\n condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the\n quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment\n fault (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "COMMUNICATIONS_ALARM", + "PROCESSING_ERROR_ALARM", + "ENVIRONMENTAL_ALARM", + "QOS_ALARM", + "EQUIPMENT_ALARM" + ] + } + }, + "probableCauses": { + "description": "Match VNF alarms with a probable cause listed in this attribute.\n", + "type": "array", + "items": { + "type": "string" + } + } + } + }, + "callbackUri": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + }, + "_links": { + "description": "Links for this resource.\n", + "type": "object", + "required": [ + "self" + ], + "properties": { + "self": { + "description": "This type represents a link to a resource using an absolute URI.\n", + "type": "object", + "required": [ + "href" + ], + "properties": { + "href": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + } + } + } + } + } + } + } + } + } + } + }, + "subscription.get.200": { + "description": "200 OK\nThe operation has completed successfully. The response body shall contain a representation of the subscription resource.\n", + "headers": { + "Content-Type": { + "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n", + "schema": { + "type": "string", + "minimum": 1, + "maximum": 1 + } + }, + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "minimum": 0, + "maximum": 1 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "minimum": 1, + "maximum": 1 + } + } + }, + "content": { + "application/json": { + "schema": { + "description": "This type represents a subscription related to notifications about VNF faults.\n", + "type": "object", + "required": [ + "id", + "callbackUri", + "_links" + ], + "properties": { + "id": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "filter": { + "description": "This type represents a subscription filter related to notifications about NFV-MANO functional entity faults. It shall comply with the provisions defined in table 7.6.3.2-1. At a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\n", + "type": "object", + "properties": { + "notificationTypes": { + "description": "Match particular notification types. Permitted values: * AlarmNotification * AlarmClearedNotification * AlarmListRebuiltNotification The permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the notification types to facilitate automated code generation systems.\n", + "type": "array", + "items": { + "type": "string", + "enum": [ + "AlarmNotification", + "AlarmClearedNotification", + "AlarmListRebuiltNotification" + ] + } + }, + "perceivedSeverities": { + "description": "Match VNF alarms with a perceived severity listed in this attribute.\n", + "type": "array", + "items": { + "description": "Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service\n affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting\n condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a\n non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a\n potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the\n severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or\n more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "CRITICAL", + "MAJOR", + "MINOR", + "WARNING", + "INDETERMINATE", + "CLEARED" + ] + } + }, + "eventTypes": { + "description": "Match VNF alarms with an event type listed in this attribute.\n", + "type": "array", + "items": { + "description": "The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the\n procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a\n software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a\n condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the\n quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment\n fault (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "COMMUNICATIONS_ALARM", + "PROCESSING_ERROR_ALARM", + "ENVIRONMENTAL_ALARM", + "QOS_ALARM", + "EQUIPMENT_ALARM" + ] + } + }, + "probableCauses": { + "description": "Match VNF alarms with a probable cause listed in this attribute.\n", + "type": "array", + "items": { + "type": "string" + } + } + } + }, + "callbackUri": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + }, + "_links": { + "description": "Links for this resource.\n", + "type": "object", + "required": [ + "self" + ], + "properties": { + "self": { + "description": "This type represents a link to a resource using an absolute URI.\n", + "type": "object", + "required": [ + "href" + ], + "properties": { + "href": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + } + } + } + } + } + } + } + } + } + }, + "subscription.delete.204": { + "description": "204 NO CONTENT\nShall be returned when the \"Individual subscription\" resource has been deleted successfully. The response body shall be empty.\n", + "headers": { + "WWW-Authenticate": { + "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n", + "schema": { + "type": "string", + "minimum": 0, + "maximum": 1 + } + }, + "Version": { + "description": "Version of the API used in the response.\n", + "schema": { + "type": "string", + "minimum": 1, + "maximum": 1 + } + } + } + } + } + } +} \ No newline at end of file diff --git a/SOL009/NFVMANOFaultManagement-API/SOL009-NFVMANOFaultManagement-API.yaml b/SOL009/NFVMANOFaultManagement-API/SOL009-NFVMANOFaultManagement-API.yaml new file mode 100644 index 000000000..5f0cf5240 --- /dev/null +++ b/SOL009/NFVMANOFaultManagement-API/SOL009-NFVMANOFaultManagement-API.yaml @@ -0,0 +1,12122 @@ +openapi: 3.0.2 +info: + version: '1.0.0-impl:etsi.org:ETSI_NFV_OpenAPI:1' + title: SOL009 - NFV-MANO Fault Management interface + description: > + SOL009 - NFV-MANO Fault Management 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. + + 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 009 V3.3.1 + url: >- + https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/009/03.03.01_60/gs_NFV-SOL009v030301p.pdf +servers: + - url: 'http://127.0.0.1/nfvmanofm/v1' + - url: 'https://127.0.0.1/nfvmanofm/v1' +paths: + /api_versions: + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: false + schema: + type: string + - name: Authorization + description: 'The authorization token for the request. Reference: IETF RFC 7235' + in: header + required: false + schema: + type: string + get: + summary: Retrieve API version information + description: > + The GET method reads API version information. This method shall follow + the provisions specified in table 4.6.3.3.3.2-1 for request and response + data structures, and response codes. URI query parameters are not + supported. + responses: + '200': + description: > + 200 OK + + API version information was read successfully. The response body + shall contain 4.4 API version information, as defined in clause + 4.4.1.13. + content: + application/json: + schema: + description: | + This type represents API version information. + type: object + required: + - uriPrefix + - apiVersions + properties: + uriPrefix: + description: > + Specifies the URI prefix for the API, in the following + form {apiRoot}/{apiName}/{apiMajorVersion}/. + type: string + apiVersions: + description: > + Version(s) supported for the API signaled by the uriPrefix + attribute. + type: array + items: + type: object + required: + - version + properties: + version: + description: > + Identifies a supported version. The value of the + version attribute shall be a version identifier as + specified in clause 9.1 (SOL013). + type: string + isDeprecated: + description: > + If such information is available, this attribute + indicates whether use of the version signaled by the + version attribute is deprecated (true) or not + (false). + + A deprecated version is still supported by the API + producer but is recommended not to be used any + longer. When a version is no longer supported, it + does not appear in the response body. + type: boolean + retirementDate: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: The used API version. + schema: + type: string + maximum: 1 + minimum: 1 + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the payload body + contains a syntactically incorrect data structure), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + 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. + + 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. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 401 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 403 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 404 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. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a payload body with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 405 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. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 406 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. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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 + '413': + description: > + 413 PAYLOAD TOO LARGE + + If the payload body of a request is larger than the amount of data + the API producer is willing or able to process, it shall respond + with this response code, following the provisions in IETF RFC 7231 + for the use of the "Retry-After" HTTP header and for closing the + connection. The "ProblemDetails" structure may be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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 + '414': + description: > + 414 URI TOO LONG + + If the request URI of a request is longer than the API producer is + willing or able to process, it shall respond with this response + code. This condition can e.g. be caused by passing long queries in + the request URI of a GET request. The "ProblemDetails" structure may + be omitted. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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 + '416': + description: | + 416 Range Not Satisfiable + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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 + '422': + description: > + 422 UNPROCESSABLE ENTITY + + If the payload body of a request contains syntactically correct data + (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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 + '429': + description: > + 429 TOO MANY REQUESTS + + If the API consumer has sent too many requests in a defined period + of time and the API producer is able to detect that condition ("rate + limiting"), the API producer shall respond with this response code, + following the provisions in IETF RFC 6585 [17] for the use of the + "Retry-After" HTTP header. The "ProblemDetails" structure shall be + provided and shall include in the "detail" attribute more + information about the source of the problem. + + The period of time and allowed number of requests are configured + within the API producer by means outside the scope of the present + document. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 500 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 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 503 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 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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 + /alarms: + get: + description: > + Get Alarm List. The client can use this method to retrieve information + about the alarm list. This method shall follow the provisions specified + in the tables 7.5.3.3.2-1 and 7.5.3.3.2-2 for URI query parameters, + request and response data structures, and response codes. + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: filter + description: > + Attribute-based filtering expression according to clause 5.2 of ETSI + GS NFV-SOL 013. The NFV-MANO functional entity shall support + receiving this parameter as part of the URI query string. The API + consumer may supply this parameter. All attribute names that appear + in the FmSubscription and in data types referenced from it shall be + supported by the NFV-MANO functional entity in the filter + expression. + in: query + required: false + schema: + type: string + - name: nextpage_opaque_marker + description: > + Marker to obtain the next page of a paged response. Shall be + supported by the NFV-MANO functional entity if the entity supports + alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS + NFV-SOL 013 for this resource. + in: query + required: false + schema: + type: string + responses: + '200': + description: > + 200 OK + + Shall be returned when information about zero or more alarms has + been queried successfully. The response body shall contain in an + array the representations of zero or more alarms as defined in + clause 7.6.2.4. If the "filter" URI parameter was supplied in the + request, the data in the response body shall have been transformed + according to the rules specified in clause 5.2.2 of ETSI GS NFV-SOL + 013. If the NFV-MANO functional entity supports alternative 2 + (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 for this + resource, inclusion of the Link HTTP header in this response shall + follow the provisions in clause 5.4.2.3 of ETSI GS NFV-SOL 013. + headers: + Content-Type: + description: > + The MIME type of the body of the request. Reference: IETF RFC + 7231 + schema: + type: string + minimum: 1 + maximum: 1 + Version: + description: | + Version of the API used in the response. + schema: + type: string + minimum: 1 + maximum: 1 + Link: + description: > + Reference to other resources. Used for paging in the present + document. + schema: + type: string + minimum: 0 + maximum: 1 + content: + application/json: + schema: + type: array + items: + description: | + The alarm data type encapsulates information about an alarm. + type: object + required: + - id + - managedObjectId + - alarmRaisedTime + - ackState + - perceivedSeverity + - eventTime + - eventType + - probableCause + - isRootCause + - _links + properties: + id: + description: > + An identifier with the intention of being globally + unique. + type: string + managedObjectId: + description: > + An identifier with the intention of being globally + unique. + type: string + associatedFaultyInstanceId: + description: > + This type represents the identifier to reference a + managed object of a particular type. + type: object + properties: + type: + description: > + Indicates the type of managed object. Permitted + values: + - MANO_ENTITY + - MANO_SERVICE + - MANO_SERVICE_IF + - CONSUMED_MANO_IF + - MANO_ENTITY_COMPONENT + + The "MANO_ENTITY COMPONENT" is only applicable if + attribute "manoEntityComponents" in "ManoEntity" is + supported by the API producer. + type: string + enum: + - MANO_ENTITY + - MANO_SERVICE + - MANO_SERVICE_IF + - CONSUMED_MANO_IF + - MANO_ENTITY_COMPONENT + objectId: + description: > + An identifier with the intention of being globally + unique. + type: string + subObjectId: + description: > + An identifier that is unique for the respective type + within a NFV-MANO functional entity, but that need + not be globally unique. Representation: string of + variable length.. + type: string + required: + - type + - objectId + alarmRaisedTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + alarmChangedTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + alarmClearedTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + ackState: + description: > + Acknowledgement state of the alarm. Permitted values: * + UNACKNOWLEDGED * ACKNOWLEDGED. + type: string + enum: + - UNACKNOWLEDGED + - ACKNOWLEDGED + perceivedSeverity: + description: > + Indicates the relative level of urgency for operator + attention. * CRITICAL: The Critical severity level + indicates that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a + service affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the + existence of a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates the + detection of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level + indicates that the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates the + clearing of one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + eventTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + eventType: + description: > + The enumeration EventType represents those types of + events that trigger an alarm. * COMMUNICATIONS_ALARM: An + alarm of this type is associated with the + procedure and/or process required conveying information from one point + to another (ITU-T Recommendation X.733). + * PROCESSING_ERROR_ALARM: An alarm of this type is + associated with a + software or processing fault (ITU-T Recommendation X.733). + * ENVIRONMENTAL_ALARM: An alarm of this type is + associated with a + condition related to an enclosure in which the equipment resides + (ITU-T Recommendation X.733). + * QOS_ALARM: An alarm of this type is associated with + degradation in the + quality of a service (ITU-T Recommendation X.733). + * EQUIPMENT_ALARM: An alarm of this type is associated + with an equipment + fault (ITU-T Recommendation X.733). + type: string + enum: + - COMMUNICATIONS_ALARM + - PROCESSING_ERROR_ALARM + - ENVIRONMENTAL_ALARM + - QOS_ALARM + - EQUIPMENT_ALARM + faultType: + description: | + Additional information to clarify the type of the fault. + type: string + probableCause: + description: | + Information about the probable cause of the fault. + type: string + isRootCause: + description: > + Attribute indicating if this fault is the root for other + correlated alarms. If true, then the alarms listed in + the attribute CorrelatedAlarmId are caused by this + fault. + type: boolean + correlatedAlarmIds: + description: > + List of identifiers of other alarms correlated to this + fault. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + faultDetails: + description: | + Provides additional information about the fault. + type: array + items: + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + objectInstance: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the payload body + contains a syntactically incorrect data structure), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + 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. + + 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. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 401 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 403 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 404 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. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a payload body with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 405 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. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 406 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. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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 + '422': + description: > + 422 UNPROCESSABLE ENTITY + + If the payload body of a request contains syntactically correct data + (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 500 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 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 503 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 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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 + '/alarms/{alarmId}': + parameters: + - name: alarmId + description: > + Identifier of the alarm. This identifier can be retrieved from the + "id" attribute of the "alarm" attribute in the AlarmNotification or + AlarmClearedNotification. It can also be retrieved from the "id" + attribute of the applicable array element in the payload body of the + response to a GET request to the "Alarms" resource. + in: path + required: true + schema: + type: string + get: + description: > + The client can use this method to read an individual alarm. This method + shall follow the provisions specified in the tables 7.5.4.3.2-1 and + 7.5.4.3.2-2 for URI query parameters, request and response data + structures, and response codes. + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + responses: + '200': + description: > + 200 OK + + Shall be returned when information about an individual alarm has + been read successfully. The response body shall contain a + representation of the individual alarm + headers: + Content-Type: + description: > + The MIME type of the body of the request. Reference: IETF RFC + 7231 + schema: + type: string + minimum: 1 + maximum: 1 + content: + application/json: + schema: + description: | + The alarm data type encapsulates information about an alarm. + type: object + required: + - id + - managedObjectId + - alarmRaisedTime + - ackState + - perceivedSeverity + - eventTime + - eventType + - probableCause + - isRootCause + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + managedObjectId: + description: | + An identifier with the intention of being globally unique. + type: string + associatedFaultyInstanceId: + description: > + This type represents the identifier to reference a managed + object of a particular type. + type: object + properties: + type: + description: > + Indicates the type of managed object. Permitted + values: + - MANO_ENTITY + - MANO_SERVICE + - MANO_SERVICE_IF + - CONSUMED_MANO_IF + - MANO_ENTITY_COMPONENT + + The "MANO_ENTITY COMPONENT" is only applicable if + attribute "manoEntityComponents" in "ManoEntity" is + supported by the API producer. + type: string + enum: + - MANO_ENTITY + - MANO_SERVICE + - MANO_SERVICE_IF + - CONSUMED_MANO_IF + - MANO_ENTITY_COMPONENT + objectId: + description: > + An identifier with the intention of being globally + unique. + type: string + subObjectId: + description: > + An identifier that is unique for the respective type + within a NFV-MANO functional entity, but that need not + be globally unique. Representation: string of variable + length.. + type: string + required: + - type + - objectId + alarmRaisedTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + alarmChangedTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + alarmClearedTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + ackState: + description: > + Acknowledgement state of the alarm. Permitted values: * + UNACKNOWLEDGED * ACKNOWLEDGED. + type: string + enum: + - UNACKNOWLEDGED + - ACKNOWLEDGED + perceivedSeverity: + description: > + Indicates the relative level of urgency for operator + attention. * CRITICAL: The Critical severity level + indicates that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a service + affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the existence + of a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates the + detection of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level + indicates that the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates the + clearing of one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + eventTime: + description: > + Date-time stamp. Representation: String formatted + according to IETF RFC 3339. + type: string + format: date-time + eventType: + description: > + The enumeration EventType represents those types of events + that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of + this type is associated with the + procedure and/or process required conveying information from one point + to another (ITU-T Recommendation X.733). + * PROCESSING_ERROR_ALARM: An alarm of this type is + associated with a + software or processing fault (ITU-T Recommendation X.733). + * ENVIRONMENTAL_ALARM: An alarm of this type is associated + with a + condition related to an enclosure in which the equipment resides + (ITU-T Recommendation X.733). + * QOS_ALARM: An alarm of this type is associated with + degradation in the + quality of a service (ITU-T Recommendation X.733). + * EQUIPMENT_ALARM: An alarm of this type is associated + with an equipment + fault (ITU-T Recommendation X.733). + type: string + enum: + - COMMUNICATIONS_ALARM + - PROCESSING_ERROR_ALARM + - ENVIRONMENTAL_ALARM + - QOS_ALARM + - EQUIPMENT_ALARM + faultType: + description: | + Additional information to clarify the type of the fault. + type: string + probableCause: + description: | + Information about the probable cause of the fault. + type: string + isRootCause: + description: > + Attribute indicating if this fault is the root for other + correlated alarms. If true, then the alarms listed in the + attribute CorrelatedAlarmId are caused by this fault. + type: boolean + correlatedAlarmIds: + description: > + List of identifiers of other alarms correlated to this + fault. + type: array + items: + description: > + An identifier with the intention of being globally + unique. + type: string + faultDetails: + description: | + Provides additional information about the fault. + type: array + items: + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + objectInstance: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the payload body + contains a syntactically incorrect data structure), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + 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. + + 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. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 401 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 403 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 404 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. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a payload body with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 405 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. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 406 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. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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 + '422': + description: > + 422 UNPROCESSABLE ENTITY + + If the payload body of a request contains syntactically correct data + (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 500 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 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 503 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 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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 + patch: + description: > + This method modifies an "Individual alarm" resource. This method shall + follow the provisions specified in the tables 7.5.4.3.4-1 and + 7.5.4.3.4-2 for URI query parameters, request and response data + structures, and response codes. + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + requestBody: + description: > + The parameter for the alarm modification, as defined in clause + 7.6.2.8. The Content-Type header shall be set to + "application/merge-patch+json" according to IETF RFC 7396. + content: + application/json: + schema: + description: > + This type represents attribute modifications for an "Individual + alarm" resource, i.e. modifications to a resource representation + based on the "Alarm" data type. The attributes of "Alarm" that + can be modified are included in the "AlarmModifications" data + type. + type: object + required: + - ackState + properties: + ackState: + description: > + New value of the "ackState" attribute in "Alarm". Permitted + values: * ACKNOWLEDGED + type: string + enum: + - ACKNOWLEDGED + required: true + responses: + '200': + description: > + 200 OK + + Shall be returned when the request has been accepted and completed. + ì The response body shall contain attribute modifications for an + "Individual alarm" resource (see clause 7.6.2.4). + headers: + Content-Type: + description: > + The MIME type of the body of the request. Reference: IETF RFC + 7231 + schema: + type: string + minimum: 1 + maximum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + minimum: 0 + maximum: 1 + content: + application/json: + schema: + description: > + This type represents attribute modifications for an + "Individual alarm" resource, i.e. modifications to a resource + representation based on the "Alarm" data type. The attributes + of "Alarm" that can be modified are included in the + "AlarmModifications" data type. + type: object + required: + - ackState + properties: + ackState: + description: > + New value of the "ackState" attribute in "Alarm". + Permitted values: * ACKNOWLEDGED + type: string + enum: + - ACKNOWLEDGED + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the payload body + contains a syntactically incorrect data structure), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + 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. + + 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. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 401 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 403 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 404 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. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a payload body with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 405 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. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 406 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. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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 + '409': + description: | + 409 CONFLICT + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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 + '412': + description: > + 412 PRECONDITION FAILED + + Error: A precondition given in an HTTP request header is not + fulfilled. Typically, this is due to an ETag mismatch, indicating + that the resource was modified by another entity. The response body + should contain a ProblemDetails structure, in which the "detail" + attribute should convey more information about the error. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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 + '422': + description: > + 422 UNPROCESSABLE ENTITY + + If the payload body of a request contains syntactically correct data + (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 500 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 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 503 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 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The description column only provides some + explanation of the meaning to Facilitate understanding of the + design. For a full description, see IETF RFC 7807 [19]. + type: object + required: + - status + - detail + properties: + type: + description: > + A URI reference according to IETF RFC 3986 [5] that + identifies the problem type. It is encouraged that the URI + provides human-readable documentation for the problem + (e.g. using HTML) when dereferenced. When this member is + not present, its value is assumed to be "about:blank". + type: string + format: URI + title: + description: > + A short, human-readable summary of the problem type. It + should not change from occurrence to occurrence of the + problem, except for purposes of localization. If type is + given and other than "about:blank", this attribute shall + also be provided. A short, human-readable summary of the + problem type. It SHOULD NOT change from occurrence to + occurrence of the problem, except for purposes of + localization (e.g., using proactive content negotiation; + see [RFC7231], Section 3.4). + type: string + status: + description: > + The HTTP status code for this occurrence of the problem. + The HTTP status code ([RFC7231], Section 6) generated by + the origin server for this occurrence of the problem. + type: integer + detail: + description: > + A human-readable explanation specific to this occurrence + of the problem. + type: string + instance: + description: > + A URI reference that identifies the specific occurrence of + the problem. It may yield further information if + dereferenced. + type: string + format: URI + /subscriptions: + post: + description: > + Subscribe. The POST method creates a new subscription. This method shall + follow the provisions specified in the tables 7.5.5.3.1-1 and + 7.5.5.3.1-2 for URI query parameters, request and response data + structures, and response codes. As the result of successfully executing + this method, a new "Individual subscription" resource as defined in + clause 7.5.6 shall have been created. This method shall not trigger any + notification. Creation of two "Individual subscription" resources with + the same callbackURI and the same filter can result in performance + degradation and will provide duplicates of notifications to the API + consumer, and might make sense only in very rare use cases. + Consequently, the NFV-MANO functional entity may either allow creating a + new "Individual subscription" resource if another "Individual + 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 "Individual subscription" + resource (in which case it shall return a "303 See Other" response code + referencing the existing "Individual subscription" resource with the + same filter and callbackUri). + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: Content-Type + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + in: header + required: true + schema: + type: string + requestBody: + description: > + Details of the subscription to be created, as defined in clause + 7.6.2.2. + content: + application/json: + schema: + description: > + This type represents a subscription request related to + notifications about NFV-MANO faults. + type: object + required: + - callbackUri + properties: + filter: + description: > + This type represents a subscription filter related to + notifications about NFV-MANO functional entity faults. It + shall comply with the provisions defined in table 7.6.3.2-1. + 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: + notificationTypes: + description: > + Match particular notification types. Permitted values: * + AlarmNotification * AlarmClearedNotification * + AlarmListRebuiltNotification The permitted values of the + "notificationTypes" attribute are spelled exactly as the + names of the notification types to facilitate automated + code generation systems. + type: array + items: + type: string + enum: + - AlarmNotification + - AlarmClearedNotification + - AlarmListRebuiltNotification + perceivedSeverities: + description: > + Match VNF alarms with a perceived severity listed in + this attribute. + type: array + items: + description: > + Indicates the relative level of urgency for operator + attention. * CRITICAL: The Critical severity level + indicates that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a + service affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the + existence of a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates the + detection of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level + indicates that the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates the + clearing of one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + eventTypes: + description: > + Match VNF alarms with an event type listed in this + attribute. + type: array + items: + description: > + The enumeration EventType represents those types of + events that trigger an alarm. * COMMUNICATIONS_ALARM: + An alarm of this type is associated with the + procedure and/or process required conveying information from one point + to another (ITU-T Recommendation X.733). + * PROCESSING_ERROR_ALARM: An alarm of this type is + associated with a + software or processing fault (ITU-T Recommendation X.733). + * ENVIRONMENTAL_ALARM: An alarm of this type is + associated with a + condition related to an enclosure in which the equipment resides + (ITU-T Recommendation X.733). + * QOS_ALARM: An alarm of this type is associated with + degradation in the + quality of a service (ITU-T Recommendation X.733). + * EQUIPMENT_ALARM: An alarm of this type is associated + with an equipment + fault (ITU-T Recommendation X.733). + type: string + enum: + - COMMUNICATIONS_ALARM + - PROCESSING_ERROR_ALARM + - ENVIRONMENTAL_ALARM + - QOS_ALARM + - EQUIPMENT_ALARM + probableCauses: + description: > + Match VNF alarms with a probable cause listed in this + attribute. + type: array + items: + 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 + required: true + responses: + '201': + description: > + 201 CREATED + + Shall be returned when the subscription has been created + successfully. The response body shall contain a representation of + the created "Individual subscription" resource. The HTTP response + shall include a "Location:"" HTTP header that points to the created + "Individual subscription" resource. + headers: + Content-Type: + description: > + The MIME type of the body of the request. Reference: IETF RFC + 7231 + schema: + type: string + minimum: 1 + maximum: 1 + Location: + description: | + The resource URI of the created subscription resource. + schema: + type: string + format: url + minimum: 1 + maximum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + minimum: 0 + maximum: 1 + content: + application/json: + schema: + description: > + This type represents a subscription related to notifications + about VNF faults. + 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 NFV-MANO functional entity faults. It + shall comply with the provisions defined in table + 7.6.3.2-1. 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: + notificationTypes: + description: > + Match particular notification types. Permitted values: + * AlarmNotification * AlarmClearedNotification * + AlarmListRebuiltNotification The permitted values of + the "notificationTypes" attribute are spelled exactly + as the names of the notification types to facilitate + automated code generation systems. + type: array + items: + type: string + enum: + - AlarmNotification + - AlarmClearedNotification + - AlarmListRebuiltNotification + perceivedSeverities: + description: > + Match VNF alarms with a perceived severity listed in + this attribute. + type: array + items: + description: > + Indicates the relative level of urgency for operator + attention. * CRITICAL: The Critical severity level + indicates that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a + service affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the + existence of a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates the + detection of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level + indicates that the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates the + clearing of one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + eventTypes: + description: > + Match VNF alarms with an event type listed in this + attribute. + type: array + items: + description: > + The enumeration EventType represents those types of + events that trigger an alarm. * + COMMUNICATIONS_ALARM: An alarm of this type is + associated with the + procedure and/or process required conveying information from one point + to another (ITU-T Recommendation X.733). + * PROCESSING_ERROR_ALARM: An alarm of this type is + associated with a + software or processing fault (ITU-T Recommendation X.733). + * ENVIRONMENTAL_ALARM: An alarm of this type is + associated with a + condition related to an enclosure in which the equipment resides + (ITU-T Recommendation X.733). + * QOS_ALARM: An alarm of this type is associated + with degradation in the + quality of a service (ITU-T Recommendation X.733). + * EQUIPMENT_ALARM: An alarm of this type is + associated with an equipment + fault (ITU-T Recommendation X.733). + type: string + enum: + - COMMUNICATIONS_ALARM + - PROCESSING_ERROR_ALARM + - ENVIRONMENTAL_ALARM + - QOS_ALARM + - EQUIPMENT_ALARM + probableCauses: + description: > + Match VNF alarms with a probable cause listed in this + attribute. + type: array + items: + 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 using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + '303': + description: | + 303 See Other + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the payload body + contains a syntactically incorrect data structure), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + 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. + + 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. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 401 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 403 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 404 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. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a payload body with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 405 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. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 406 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. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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 + '422': + description: > + 422 UNPROCESSABLE ENTITY + + If the payload body of a request contains syntactically correct data + (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 500 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 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 503 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 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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 client can use this method to retrieve the list of active + subscriptions for NFV-MANO functional entity alarms subscribed by the + client. It can be used e.g. for resynchronization after error + situations. This method shall follow the provisions specified in the + tables 7.5.5.3.2-1 and 7.5.5.3.2-2 for URI query parameters, request and + response data structures, and response codes. + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + - name: filter + description: > + Attribute-based filtering expression according to clause 5.2 of ETSI + GS NFV-SOL 013. The NFV-MANO functional entity shall support + receiving this parameter as part of the URI query string. The API + consumer may supply this parameter. All attribute names that appear + in the FmSubscription and in data types referenced from it shall be + supported by the NFV-MANO functional entity in the filter + expression. + in: query + required: false + schema: + type: string + - name: nextpage_opaque_marker + description: > + Marker to obtain the next page of a paged response. Shall be + supported by the NFV-MANO functional entity if the entity supports + alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS + NFV-SOL 013 for this resource. + in: query + required: false + schema: + type: string + responses: + '200': + description: > + 200 OK + + Shall be returned when the list of subscriptions has been queried + successfully. The response body shall contain in an array the + representations of all active subscriptions of the functional block + that invokes the method, i.e. zero or more representations of FM + subscriptions as defined in clause 7.6.2.3. If the "filter" URI + parameter was supplied in the request, the data in the response body + shall have been transformed according to the rules specified in + clause 5.2.2 of ETSI GS NFV-SOL 013. If the NFV-MANO functional + entity supports alternative 2 (paging) according to clause 5.4.2.1 + of ETSI GS NFV-SOL 013 for this resource, inclusion of the Link HTTP + header in this response shall follow the provisions in clause + 5.4.2.3 of ETSI GS NFV-SOL 013. + headers: + Content-Type: + description: > + The MIME type of the body of the request. Reference: IETF RFC + 7231 + schema: + type: string + minimum: 1 + maximum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + minimum: 0 + maximum: 1 + Version: + description: | + Version of the API used in the response. + schema: + type: string + minimum: 1 + maximum: 1 + Link: + description: > + Reference to other resources. Used for paging in the present + document, see clause 4.7.2.1. + schema: + type: string + minimum: 0 + maximum: 1 + content: + application/json: + schema: + type: array + items: + description: > + This type represents a subscription related to notifications + about VNF faults. + 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 NFV-MANO functional entity faults. + It shall comply with the provisions defined in table + 7.6.3.2-1. 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: + notificationTypes: + description: > + Match particular notification types. Permitted + values: * AlarmNotification * + AlarmClearedNotification * + AlarmListRebuiltNotification The permitted values of + the "notificationTypes" attribute are spelled + exactly as the names of the notification types to + facilitate automated code generation systems. + type: array + items: + type: string + enum: + - AlarmNotification + - AlarmClearedNotification + - AlarmListRebuiltNotification + perceivedSeverities: + description: > + Match VNF alarms with a perceived severity listed in + this attribute. + type: array + items: + description: > + Indicates the relative level of urgency for + operator attention. * CRITICAL: The Critical + severity level indicates that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a + service affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the + existence of a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates + the detection of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level + indicates that the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates + the clearing of one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + eventTypes: + description: > + Match VNF alarms with an event type listed in this + attribute. + type: array + items: + description: > + The enumeration EventType represents those types + of events that trigger an alarm. * + COMMUNICATIONS_ALARM: An alarm of this type is + associated with the + procedure and/or process required conveying information from one point + to another (ITU-T Recommendation X.733). + * PROCESSING_ERROR_ALARM: An alarm of this type is + associated with a + software or processing fault (ITU-T Recommendation X.733). + * ENVIRONMENTAL_ALARM: An alarm of this type is + associated with a + condition related to an enclosure in which the equipment resides + (ITU-T Recommendation X.733). + * QOS_ALARM: An alarm of this type is associated + with degradation in the + quality of a service (ITU-T Recommendation X.733). + * EQUIPMENT_ALARM: An alarm of this type is + associated with an equipment + fault (ITU-T Recommendation X.733). + type: string + enum: + - COMMUNICATIONS_ALARM + - PROCESSING_ERROR_ALARM + - ENVIRONMENTAL_ALARM + - QOS_ALARM + - EQUIPMENT_ALARM + probableCauses: + description: > + Match VNF alarms with a probable cause listed in + this attribute. + type: array + items: + 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 using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the payload body + contains a syntactically incorrect data structure), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + 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. + + 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. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 401 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 403 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 404 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. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a payload body with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 405 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. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 406 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. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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 + '422': + description: > + 422 UNPROCESSABLE ENTITY + + If the payload body of a request contains syntactically correct data + (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 500 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 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 503 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 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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 "Individual subscription" resource. + It can also be retrieved from the "id" attribute in the payload body + of that response. + in: path + required: true + schema: + type: string + get: + description: > + Query Subscription Information. The client can use this method for + reading an individual subscription for NFV-MANO functional entity alarms + subscribed by the client. This method shall follow the provisions + specified in the tables 7.5.6.3.2-1 and 7.5.6.3.2-2 for URI query + parameters, request and response data structures, and response codes. + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Accept + description: > + Content-Types that are acceptable for the response. Reference: IETF + RFC 7231. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + responses: + '200': + description: > + 200 OK + + The operation has completed successfully. The response body shall + contain a representation of the subscription resource. + headers: + Content-Type: + description: > + The MIME type of the body of the request. Reference: IETF RFC + 7231 + schema: + type: string + minimum: 1 + maximum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + minimum: 0 + maximum: 1 + Version: + description: | + Version of the API used in the response. + schema: + type: string + minimum: 1 + maximum: 1 + content: + application/json: + schema: + description: > + This type represents a subscription related to notifications + about VNF faults. + 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 NFV-MANO functional entity faults. It + shall comply with the provisions defined in table + 7.6.3.2-1. 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: + notificationTypes: + description: > + Match particular notification types. Permitted values: + * AlarmNotification * AlarmClearedNotification * + AlarmListRebuiltNotification The permitted values of + the "notificationTypes" attribute are spelled exactly + as the names of the notification types to facilitate + automated code generation systems. + type: array + items: + type: string + enum: + - AlarmNotification + - AlarmClearedNotification + - AlarmListRebuiltNotification + perceivedSeverities: + description: > + Match VNF alarms with a perceived severity listed in + this attribute. + type: array + items: + description: > + Indicates the relative level of urgency for operator + attention. * CRITICAL: The Critical severity level + indicates that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a + service affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the + existence of a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates the + detection of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level + indicates that the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates the + clearing of one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + eventTypes: + description: > + Match VNF alarms with an event type listed in this + attribute. + type: array + items: + description: > + The enumeration EventType represents those types of + events that trigger an alarm. * + COMMUNICATIONS_ALARM: An alarm of this type is + associated with the + procedure and/or process required conveying information from one point + to another (ITU-T Recommendation X.733). + * PROCESSING_ERROR_ALARM: An alarm of this type is + associated with a + software or processing fault (ITU-T Recommendation X.733). + * ENVIRONMENTAL_ALARM: An alarm of this type is + associated with a + condition related to an enclosure in which the equipment resides + (ITU-T Recommendation X.733). + * QOS_ALARM: An alarm of this type is associated + with degradation in the + quality of a service (ITU-T Recommendation X.733). + * EQUIPMENT_ALARM: An alarm of this type is + associated with an equipment + fault (ITU-T Recommendation X.733). + type: string + enum: + - COMMUNICATIONS_ALARM + - PROCESSING_ERROR_ALARM + - ENVIRONMENTAL_ALARM + - QOS_ALARM + - EQUIPMENT_ALARM + probableCauses: + description: > + Match VNF alarms with a probable cause listed in this + attribute. + type: array + items: + 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 using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the payload body + contains a syntactically incorrect data structure), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + 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. + + 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. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 401 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 403 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 404 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. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a payload body with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 405 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. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 406 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. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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 + '422': + description: > + 422 UNPROCESSABLE ENTITY + + If the payload body of a request contains syntactically correct data + (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 500 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 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 503 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 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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. This method terminates an individual subscription. This method shall follow the provisions specified in the tables 7.5.6.3.5-1 and 7.5.6.3.5-2 for URI query parameters, request and response data structures, and response codes. As the result of successfully executing this method, the \"Individual subscription\" resource shall not exist any longer. This means that no notifications for that subscription shall be sent to the formerly-subscribed API consumer. NOTE:\tDue to race conditions, some notifications might still be received by the formerly-subscribed API consumer for a certain time period after the deletion.\n" + parameters: + - name: Version + description: | + Version of the API requested to use when responding to this request. + in: header + required: true + schema: + type: string + - name: Authorization + description: | + The authorization token for the request. Reference: IETF RFC 7235. + in: header + required: false + schema: + type: string + responses: + '204': + description: > + 204 NO CONTENT + + Shall be returned when the "Individual subscription" resource has + been deleted successfully. The response body shall be empty. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + minimum: 0 + maximum: 1 + Version: + description: | + Version of the API used in the response. + schema: + type: string + minimum: 1 + maximum: 1 + '400': + description: > + 400 BAD REQUEST + + 400 code can be returned in the following specified cases, the + specific cause has to be proper specified in the "ProblemDetails" + structure to be returned. + + If the request is malformed or syntactically incorrect (e.g. if the + request URI contains incorrect query parameters or the payload body + contains a syntactically incorrect data structure), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + If the response to a GET request which queries a container resource + would be so big that the performance of the API producer is + adversely affected, and the API producer does not support paging for + the affected resource, it shall respond with this response code. The + "ProblemDetails" structure shall be provided, and should include in + the "detail" attribute more information about the source of the + problem. + + 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. + + 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. + + The use of this HTTP error response code described above is + applicable to the use of the OAuth 2.0 for the authorization of API + requests and notifications, as defined in clauses 4.5.3.3 and + 4.5.3.4. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 401 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 403 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 404 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. + + This response code is not appropriate in case the resource addressed + by the URI is a container resource which is designed to contain + child resources, but does not contain any child resource at the time + the request is received. For a GET request to an existing empty + container resource, a typical response contains a 200 OK response + code and a payload body with an empty array. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 405 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. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 406 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. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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 + '422': + description: > + 422 UNPROCESSABLE ENTITY + + If the payload body of a request contains syntactically correct data + (e.g. well-formed JSON) but the data cannot be processed (e.g. + because it fails validation against a schema), the API producer + shall respond with this response code. The "ProblemDetails" + structure shall be provided, and should include in the "detail" + attribute more information about the source of the problem. + + This error response code is only applicable for methods that have a + request body. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 500 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 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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: > + 503 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 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. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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 + '504': + description: > + 504 GATEWAY TIMEOUT + + If the API producer encounters a timeout while waiting for a + response from an upstream server (i.e. a server that the API + producer communicates with when fulfilling a request), it should + respond with this response code. + headers: + Content-Type: + description: The MIME type of the body of the response. + schema: + type: string + maximum: 1 + minimum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP + request has provided an invalid authorization token. + schema: + type: string + maximum: 1 + minimum: 0 + Version: + description: | + Version of the API used in the response. + schema: + type: string + maximum: 1 + minimum: 1 + content: + application/json: + schema: + description: > + The definition of the general "ProblemDetails" data structure + from IETF RFC 7807 [19] is reproduced inthis structure. + Compared to the general framework defined in IETF RFC 7807 + [19], the "status" and "detail" attributes are mandated to be + included by the present document, to ensure that the response + contains additional textual information about an error. IETF + RFC 7807 [19] foresees extensibility of the "ProblemDetails" + type. It is possible that particular APIs in the present + document, or particular implementations, define extensions to + define additional attributes that provide more information + about the error. The 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 +components: + parameters: + alarmId: + name: alarmId + description: > + Identifier of the alarm. This identifier can be retrieved from the "id" + attribute of the "alarm" attribute in the AlarmNotification or + AlarmClearedNotification. It can also be retrieved from the "id" + attribute of the applicable array element in the payload body of the + response to a GET request to the "Alarms" resource. + in: path + required: true + schema: + type: string + subscriptionId: + 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 "Individual subscription" resource. It can + also be retrieved from the "id" attribute in the payload body of that + response. + in: path + required: true + schema: + type: string + schemas: + FmSubscriptionRequest: + description: > + This type represents a subscription request related to notifications + about NFV-MANO faults. + type: object + required: + - callbackUri + properties: + filter: + description: > + This type represents a subscription filter related to notifications + about NFV-MANO functional entity faults. It shall comply with the + provisions defined in table 7.6.3.2-1. 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: + notificationTypes: + description: > + Match particular notification types. Permitted values: * + AlarmNotification * AlarmClearedNotification * + AlarmListRebuiltNotification The permitted values of the + "notificationTypes" attribute are spelled exactly as the names + of the notification types to facilitate automated code + generation systems. + type: array + items: + type: string + enum: + - AlarmNotification + - AlarmClearedNotification + - AlarmListRebuiltNotification + perceivedSeverities: + description: > + Match VNF alarms with a perceived severity listed in this + attribute. + type: array + items: + description: > + Indicates the relative level of urgency for operator + attention. * CRITICAL: The Critical severity level indicates + that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a service + affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the existence of a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates the detection + of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level indicates + that the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates the clearing + of one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + eventTypes: + description: | + Match VNF alarms with an event type listed in this attribute. + type: array + items: + description: > + The enumeration EventType represents those types of events + that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of + this type is associated with the + procedure and/or process required conveying information from one point + to another (ITU-T Recommendation X.733). + * PROCESSING_ERROR_ALARM: An alarm of this type is associated + with a + software or processing fault (ITU-T Recommendation X.733). + * ENVIRONMENTAL_ALARM: An alarm of this type is associated + with a + condition related to an enclosure in which the equipment resides + (ITU-T Recommendation X.733). + * QOS_ALARM: An alarm of this type is associated with + degradation in the + quality of a service (ITU-T Recommendation X.733). + * EQUIPMENT_ALARM: An alarm of this type is associated with an + equipment + fault (ITU-T Recommendation X.733). + type: string + enum: + - COMMUNICATIONS_ALARM + - PROCESSING_ERROR_ALARM + - ENVIRONMENTAL_ALARM + - QOS_ALARM + - EQUIPMENT_ALARM + probableCauses: + description: | + Match VNF alarms with a probable cause listed in this attribute. + type: array + items: + 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 + FmSubscription: + description: > + This type represents a subscription related to notifications about VNF + faults. + 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 NFV-MANO functional entity faults. It shall comply with the + provisions defined in table 7.6.3.2-1. 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: + notificationTypes: + description: > + Match particular notification types. Permitted values: * + AlarmNotification * AlarmClearedNotification * + AlarmListRebuiltNotification The permitted values of the + "notificationTypes" attribute are spelled exactly as the names + of the notification types to facilitate automated code + generation systems. + type: array + items: + type: string + enum: + - AlarmNotification + - AlarmClearedNotification + - AlarmListRebuiltNotification + perceivedSeverities: + description: > + Match VNF alarms with a perceived severity listed in this + attribute. + type: array + items: + description: > + Indicates the relative level of urgency for operator + attention. * CRITICAL: The Critical severity level indicates + that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a service + affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the existence of a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates the detection + of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level indicates + that the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates the clearing + of one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + eventTypes: + description: | + Match VNF alarms with an event type listed in this attribute. + type: array + items: + description: > + The enumeration EventType represents those types of events + that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of + this type is associated with the + procedure and/or process required conveying information from one point + to another (ITU-T Recommendation X.733). + * PROCESSING_ERROR_ALARM: An alarm of this type is associated + with a + software or processing fault (ITU-T Recommendation X.733). + * ENVIRONMENTAL_ALARM: An alarm of this type is associated + with a + condition related to an enclosure in which the equipment resides + (ITU-T Recommendation X.733). + * QOS_ALARM: An alarm of this type is associated with + degradation in the + quality of a service (ITU-T Recommendation X.733). + * EQUIPMENT_ALARM: An alarm of this type is associated with an + equipment + fault (ITU-T Recommendation X.733). + type: string + enum: + - COMMUNICATIONS_ALARM + - PROCESSING_ERROR_ALARM + - ENVIRONMENTAL_ALARM + - QOS_ALARM + - EQUIPMENT_ALARM + probableCauses: + description: | + Match VNF alarms with a probable cause listed in this attribute. + type: array + items: + 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 using an absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + AlarmModifications: + description: > + This type represents attribute modifications for an "Individual alarm" + resource, i.e. modifications to a resource representation based on the + "Alarm" data type. The attributes of "Alarm" that can be modified are + included in the "AlarmModifications" data type. + type: object + required: + - ackState + properties: + ackState: + description: > + New value of the "ackState" attribute in "Alarm". Permitted values: + * ACKNOWLEDGED + type: string + enum: + - ACKNOWLEDGED + FmNotificationsFilter: + description: > + This type represents a subscription filter related to notifications + about NFV-MANO functional entity faults. It shall comply with the + provisions defined in table 7.6.3.2-1. 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: + notificationTypes: + description: > + Match particular notification types. Permitted values: * + AlarmNotification * AlarmClearedNotification * + AlarmListRebuiltNotification The permitted values of the + "notificationTypes" attribute are spelled exactly as the names of + the notification types to facilitate automated code generation + systems. + type: array + items: + type: string + enum: + - AlarmNotification + - AlarmClearedNotification + - AlarmListRebuiltNotification + perceivedSeverities: + description: | + Match VNF alarms with a perceived severity listed in this attribute. + type: array + items: + description: > + Indicates the relative level of urgency for operator attention. * + CRITICAL: The Critical severity level indicates that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a service + affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the existence of a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates the detection of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level indicates that + the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates the clearing of + one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + eventTypes: + description: | + Match VNF alarms with an event type listed in this attribute. + type: array + items: + description: > + The enumeration EventType represents those types of events that + trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is + associated with the + procedure and/or process required conveying information from one point + to another (ITU-T Recommendation X.733). + * PROCESSING_ERROR_ALARM: An alarm of this type is associated with + a + software or processing fault (ITU-T Recommendation X.733). + * ENVIRONMENTAL_ALARM: An alarm of this type is associated with a + condition related to an enclosure in which the equipment resides + (ITU-T Recommendation X.733). + * QOS_ALARM: An alarm of this type is associated with degradation + in the + quality of a service (ITU-T Recommendation X.733). + * EQUIPMENT_ALARM: An alarm of this type is associated with an + equipment + fault (ITU-T Recommendation X.733). + type: string + enum: + - COMMUNICATIONS_ALARM + - PROCESSING_ERROR_ALARM + - ENVIRONMENTAL_ALARM + - QOS_ALARM + - EQUIPMENT_ALARM + probableCauses: + description: | + Match VNF alarms with a probable cause listed in this attribute. + type: array + items: + type: string + requestBodies: + AlarmModifications: + description: > + The parameter for the alarm modification, as defined in clause 7.6.2.8. + The Content-Type header shall be set to "application/merge-patch+json" + according to IETF RFC 7396. + content: + application/json: + schema: + description: > + This type represents attribute modifications for an "Individual + alarm" resource, i.e. modifications to a resource representation + based on the "Alarm" data type. The attributes of "Alarm" that can + be modified are included in the "AlarmModifications" data type. + type: object + required: + - ackState + properties: + ackState: + description: > + New value of the "ackState" attribute in "Alarm". Permitted + values: * ACKNOWLEDGED + type: string + enum: + - ACKNOWLEDGED + required: true + FmSubscriptionRequest: + description: | + Details of the subscription to be created, as defined in clause 7.6.2.2. + content: + application/json: + schema: + description: > + This type represents a subscription request related to + notifications about NFV-MANO faults. + type: object + required: + - callbackUri + properties: + filter: + description: > + This type represents a subscription filter related to + notifications about NFV-MANO functional entity faults. It + shall comply with the provisions defined in table 7.6.3.2-1. + 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: + notificationTypes: + description: > + Match particular notification types. Permitted values: * + AlarmNotification * AlarmClearedNotification * + AlarmListRebuiltNotification The permitted values of the + "notificationTypes" attribute are spelled exactly as the + names of the notification types to facilitate automated + code generation systems. + type: array + items: + type: string + enum: + - AlarmNotification + - AlarmClearedNotification + - AlarmListRebuiltNotification + perceivedSeverities: + description: > + Match VNF alarms with a perceived severity listed in this + attribute. + type: array + items: + description: > + Indicates the relative level of urgency for operator + attention. * CRITICAL: The Critical severity level + indicates that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a + service affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the + existence of a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates the + detection of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level + indicates that the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates the + clearing of one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + eventTypes: + description: > + Match VNF alarms with an event type listed in this + attribute. + type: array + items: + description: > + The enumeration EventType represents those types of + events that trigger an alarm. * COMMUNICATIONS_ALARM: An + alarm of this type is associated with the + procedure and/or process required conveying information from one point + to another (ITU-T Recommendation X.733). + * PROCESSING_ERROR_ALARM: An alarm of this type is + associated with a + software or processing fault (ITU-T Recommendation X.733). + * ENVIRONMENTAL_ALARM: An alarm of this type is + associated with a + condition related to an enclosure in which the equipment resides + (ITU-T Recommendation X.733). + * QOS_ALARM: An alarm of this type is associated with + degradation in the + quality of a service (ITU-T Recommendation X.733). + * EQUIPMENT_ALARM: An alarm of this type is associated + with an equipment + fault (ITU-T Recommendation X.733). + type: string + enum: + - COMMUNICATIONS_ALARM + - PROCESSING_ERROR_ALARM + - ENVIRONMENTAL_ALARM + - QOS_ALARM + - EQUIPMENT_ALARM + probableCauses: + description: > + Match VNF alarms with a probable cause listed in this + attribute. + type: array + items: + 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 + required: true + responses: + Alarms.Get: + description: > + 200 OK + + Shall be returned when information about zero or more alarms has been + queried successfully. The response body shall contain in an array the + representations of zero or more alarms as defined in clause 7.6.2.4. If + the "filter" URI parameter was supplied in the request, the data in the + response body shall have been transformed according to the rules + specified in clause 5.2.2 of ETSI GS NFV-SOL 013. If the NFV-MANO + functional entity supports alternative 2 (paging) according to clause + 5.4.2.1 of ETSI GS NFV-SOL 013 for this resource, inclusion of the Link + HTTP header in this response shall follow the provisions in clause + 5.4.2.3 of ETSI GS NFV-SOL 013. + headers: + Content-Type: + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + schema: + type: string + minimum: 1 + maximum: 1 + Version: + description: | + Version of the API used in the response. + schema: + type: string + minimum: 1 + maximum: 1 + Link: + description: > + Reference to other resources. Used for paging in the present + document. + schema: + type: string + minimum: 0 + maximum: 1 + content: + application/json: + schema: + type: array + items: + description: | + The alarm data type encapsulates information about an alarm. + type: object + required: + - id + - managedObjectId + - alarmRaisedTime + - ackState + - perceivedSeverity + - eventTime + - eventType + - probableCause + - isRootCause + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + managedObjectId: + description: | + An identifier with the intention of being globally unique. + type: string + associatedFaultyInstanceId: + description: > + This type represents the identifier to reference a managed + object of a particular type. + type: object + properties: + type: + description: > + Indicates the type of managed object. Permitted values: + - MANO_ENTITY + - MANO_SERVICE + - MANO_SERVICE_IF + - CONSUMED_MANO_IF + - MANO_ENTITY_COMPONENT + + The "MANO_ENTITY COMPONENT" is only applicable if + attribute "manoEntityComponents" in "ManoEntity" is + supported by the API producer. + type: string + enum: + - MANO_ENTITY + - MANO_SERVICE + - MANO_SERVICE_IF + - CONSUMED_MANO_IF + - MANO_ENTITY_COMPONENT + objectId: + description: > + An identifier with the intention of being globally + unique. + type: string + subObjectId: + description: > + An identifier that is unique for the respective type + within a NFV-MANO functional entity, but that need not + be globally unique. Representation: string of variable + length.. + type: string + required: + - type + - objectId + alarmRaisedTime: + description: > + Date-time stamp. Representation: String formatted according + to IETF RFC 3339. + type: string + format: date-time + alarmChangedTime: + description: > + Date-time stamp. Representation: String formatted according + to IETF RFC 3339. + type: string + format: date-time + alarmClearedTime: + description: > + Date-time stamp. Representation: String formatted according + to IETF RFC 3339. + type: string + format: date-time + ackState: + description: > + Acknowledgement state of the alarm. Permitted values: * + UNACKNOWLEDGED * ACKNOWLEDGED. + type: string + enum: + - UNACKNOWLEDGED + - ACKNOWLEDGED + perceivedSeverity: + description: > + Indicates the relative level of urgency for operator + attention. * CRITICAL: The Critical severity level indicates + that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a service + affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the existence of + a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates the + detection of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level indicates + that the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates the clearing + of one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + eventTime: + description: > + Date-time stamp. Representation: String formatted according + to IETF RFC 3339. + type: string + format: date-time + eventType: + description: > + The enumeration EventType represents those types of events + that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of + this type is associated with the + procedure and/or process required conveying information from one point + to another (ITU-T Recommendation X.733). + * PROCESSING_ERROR_ALARM: An alarm of this type is + associated with a + software or processing fault (ITU-T Recommendation X.733). + * ENVIRONMENTAL_ALARM: An alarm of this type is associated + with a + condition related to an enclosure in which the equipment resides + (ITU-T Recommendation X.733). + * QOS_ALARM: An alarm of this type is associated with + degradation in the + quality of a service (ITU-T Recommendation X.733). + * EQUIPMENT_ALARM: An alarm of this type is associated with + an equipment + fault (ITU-T Recommendation X.733). + type: string + enum: + - COMMUNICATIONS_ALARM + - PROCESSING_ERROR_ALARM + - ENVIRONMENTAL_ALARM + - QOS_ALARM + - EQUIPMENT_ALARM + faultType: + description: | + Additional information to clarify the type of the fault. + type: string + probableCause: + description: | + Information about the probable cause of the fault. + type: string + isRootCause: + description: > + Attribute indicating if this fault is the root for other + correlated alarms. If true, then the alarms listed in the + attribute CorrelatedAlarmId are caused by this fault. + type: boolean + correlatedAlarmIds: + description: > + List of identifiers of other alarms correlated to this + fault. + type: array + items: + description: | + An identifier with the intention of being globally unique. + type: string + faultDetails: + description: | + Provides additional information about the fault. + type: array + items: + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + objectInstance: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + Alarm.Get: + description: > + 200 OK + + Shall be returned when information about an individual alarm has been + read successfully. The response body shall contain a representation of + the individual alarm + headers: + Content-Type: + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + schema: + type: string + minimum: 1 + maximum: 1 + content: + application/json: + schema: + description: | + The alarm data type encapsulates information about an alarm. + type: object + required: + - id + - managedObjectId + - alarmRaisedTime + - ackState + - perceivedSeverity + - eventTime + - eventType + - probableCause + - isRootCause + - _links + properties: + id: + description: | + An identifier with the intention of being globally unique. + type: string + managedObjectId: + description: | + An identifier with the intention of being globally unique. + type: string + associatedFaultyInstanceId: + description: > + This type represents the identifier to reference a managed + object of a particular type. + type: object + properties: + type: + description: > + Indicates the type of managed object. Permitted values: + - MANO_ENTITY + - MANO_SERVICE + - MANO_SERVICE_IF + - CONSUMED_MANO_IF + - MANO_ENTITY_COMPONENT + + The "MANO_ENTITY COMPONENT" is only applicable if + attribute "manoEntityComponents" in "ManoEntity" is + supported by the API producer. + type: string + enum: + - MANO_ENTITY + - MANO_SERVICE + - MANO_SERVICE_IF + - CONSUMED_MANO_IF + - MANO_ENTITY_COMPONENT + objectId: + description: | + An identifier with the intention of being globally unique. + type: string + subObjectId: + description: > + An identifier that is unique for the respective type + within a NFV-MANO functional entity, but that need not be + globally unique. Representation: string of variable + length.. + type: string + required: + - type + - objectId + alarmRaisedTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + alarmChangedTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + alarmClearedTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + ackState: + description: > + Acknowledgement state of the alarm. Permitted values: * + UNACKNOWLEDGED * ACKNOWLEDGED. + type: string + enum: + - UNACKNOWLEDGED + - ACKNOWLEDGED + perceivedSeverity: + description: > + Indicates the relative level of urgency for operator + attention. * CRITICAL: The Critical severity level indicates + that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a service + affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the existence of a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates the detection + of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level indicates + that the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates the clearing + of one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + eventTime: + description: > + Date-time stamp. Representation: String formatted according to + IETF RFC 3339. + type: string + format: date-time + eventType: + description: > + The enumeration EventType represents those types of events + that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of + this type is associated with the + procedure and/or process required conveying information from one point + to another (ITU-T Recommendation X.733). + * PROCESSING_ERROR_ALARM: An alarm of this type is associated + with a + software or processing fault (ITU-T Recommendation X.733). + * ENVIRONMENTAL_ALARM: An alarm of this type is associated + with a + condition related to an enclosure in which the equipment resides + (ITU-T Recommendation X.733). + * QOS_ALARM: An alarm of this type is associated with + degradation in the + quality of a service (ITU-T Recommendation X.733). + * EQUIPMENT_ALARM: An alarm of this type is associated with an + equipment + fault (ITU-T Recommendation X.733). + type: string + enum: + - COMMUNICATIONS_ALARM + - PROCESSING_ERROR_ALARM + - ENVIRONMENTAL_ALARM + - QOS_ALARM + - EQUIPMENT_ALARM + faultType: + description: | + Additional information to clarify the type of the fault. + type: string + probableCause: + description: | + Information about the probable cause of the fault. + type: string + isRootCause: + description: > + Attribute indicating if this fault is the root for other + correlated alarms. If true, then the alarms listed in the + attribute CorrelatedAlarmId are caused by this fault. + type: boolean + correlatedAlarmIds: + description: | + List of identifiers of other alarms correlated to this fault. + type: array + items: + description: | + An identifier with the intention of being globally unique. + type: string + faultDetails: + description: | + Provides additional information about the fault. + type: array + items: + type: string + _links: + description: | + Links for this resource. + type: object + required: + - self + properties: + self: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + objectInstance: + description: > + This type represents a link to a resource using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + Alarm.Patch: + description: > + 200 OK + + Shall be returned when the request has been accepted and completed. ì + The response body shall contain attribute modifications for an + "Individual alarm" resource (see clause 7.6.2.4). + headers: + Content-Type: + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + schema: + type: string + minimum: 1 + maximum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP request + has provided an invalid authorization token. + schema: + type: string + minimum: 0 + maximum: 1 + content: + application/json: + schema: + description: > + This type represents attribute modifications for an "Individual + alarm" resource, i.e. modifications to a resource representation + based on the "Alarm" data type. The attributes of "Alarm" that can + be modified are included in the "AlarmModifications" data type. + type: object + required: + - ackState + properties: + ackState: + description: > + New value of the "ackState" attribute in "Alarm". Permitted + values: * ACKNOWLEDGED + type: string + enum: + - ACKNOWLEDGED + subscriptions.post.201: + description: > + 201 CREATED + + Shall be returned when the subscription has been created successfully. + The response body shall contain a representation of the created + "Individual subscription" resource. The HTTP response shall include a + "Location:"" HTTP header that points to the created "Individual + subscription" resource. + headers: + Content-Type: + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + schema: + type: string + minimum: 1 + maximum: 1 + Location: + description: | + The resource URI of the created subscription resource. + schema: + type: string + format: url + minimum: 1 + maximum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP request + has provided an invalid authorization token. + schema: + type: string + minimum: 0 + maximum: 1 + content: + application/json: + schema: + description: > + This type represents a subscription related to notifications about + VNF faults. + 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 NFV-MANO functional entity faults. It + shall comply with the provisions defined in table 7.6.3.2-1. + 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: + notificationTypes: + description: > + Match particular notification types. Permitted values: * + AlarmNotification * AlarmClearedNotification * + AlarmListRebuiltNotification The permitted values of the + "notificationTypes" attribute are spelled exactly as the + names of the notification types to facilitate automated + code generation systems. + type: array + items: + type: string + enum: + - AlarmNotification + - AlarmClearedNotification + - AlarmListRebuiltNotification + perceivedSeverities: + description: > + Match VNF alarms with a perceived severity listed in this + attribute. + type: array + items: + description: > + Indicates the relative level of urgency for operator + attention. * CRITICAL: The Critical severity level + indicates that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a + service affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the + existence of a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates the + detection of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level + indicates that the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates the + clearing of one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + eventTypes: + description: > + Match VNF alarms with an event type listed in this + attribute. + type: array + items: + description: > + The enumeration EventType represents those types of + events that trigger an alarm. * COMMUNICATIONS_ALARM: An + alarm of this type is associated with the + procedure and/or process required conveying information from one point + to another (ITU-T Recommendation X.733). + * PROCESSING_ERROR_ALARM: An alarm of this type is + associated with a + software or processing fault (ITU-T Recommendation X.733). + * ENVIRONMENTAL_ALARM: An alarm of this type is + associated with a + condition related to an enclosure in which the equipment resides + (ITU-T Recommendation X.733). + * QOS_ALARM: An alarm of this type is associated with + degradation in the + quality of a service (ITU-T Recommendation X.733). + * EQUIPMENT_ALARM: An alarm of this type is associated + with an equipment + fault (ITU-T Recommendation X.733). + type: string + enum: + - COMMUNICATIONS_ALARM + - PROCESSING_ERROR_ALARM + - ENVIRONMENTAL_ALARM + - QOS_ALARM + - EQUIPMENT_ALARM + probableCauses: + description: > + Match VNF alarms with a probable cause listed in this + attribute. + type: array + items: + 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 using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + subscriptions.get.200: + description: > + 200 OK + + Shall be returned when the list of subscriptions has been queried + successfully. The response body shall contain in an array the + representations of all active subscriptions of the functional block that + invokes the method, i.e. zero or more representations of FM + subscriptions as defined in clause 7.6.2.3. If the "filter" URI + parameter was supplied in the request, the data in the response body + shall have been transformed according to the rules specified in clause + 5.2.2 of ETSI GS NFV-SOL 013. If the NFV-MANO functional entity supports + alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL + 013 for this resource, inclusion of the Link HTTP header in this + response shall follow the provisions in clause 5.4.2.3 of ETSI GS + NFV-SOL 013. + headers: + Content-Type: + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + schema: + type: string + minimum: 1 + maximum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP request + has provided an invalid authorization token. + schema: + type: string + minimum: 0 + maximum: 1 + Version: + description: | + Version of the API used in the response. + schema: + type: string + minimum: 1 + maximum: 1 + Link: + description: > + Reference to other resources. Used for paging in the present + document, see clause 4.7.2.1. + schema: + type: string + minimum: 0 + maximum: 1 + content: + application/json: + schema: + type: array + items: + description: > + This type represents a subscription related to notifications + about VNF faults. + 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 NFV-MANO functional entity faults. It + shall comply with the provisions defined in table 7.6.3.2-1. + 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: + notificationTypes: + description: > + Match particular notification types. Permitted values: * + AlarmNotification * AlarmClearedNotification * + AlarmListRebuiltNotification The permitted values of the + "notificationTypes" attribute are spelled exactly as the + names of the notification types to facilitate automated + code generation systems. + type: array + items: + type: string + enum: + - AlarmNotification + - AlarmClearedNotification + - AlarmListRebuiltNotification + perceivedSeverities: + description: > + Match VNF alarms with a perceived severity listed in + this attribute. + type: array + items: + description: > + Indicates the relative level of urgency for operator + attention. * CRITICAL: The Critical severity level + indicates that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a + service affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the + existence of a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates the + detection of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level + indicates that the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates the + clearing of one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + eventTypes: + description: > + Match VNF alarms with an event type listed in this + attribute. + type: array + items: + description: > + The enumeration EventType represents those types of + events that trigger an alarm. * COMMUNICATIONS_ALARM: + An alarm of this type is associated with the + procedure and/or process required conveying information from one point + to another (ITU-T Recommendation X.733). + * PROCESSING_ERROR_ALARM: An alarm of this type is + associated with a + software or processing fault (ITU-T Recommendation X.733). + * ENVIRONMENTAL_ALARM: An alarm of this type is + associated with a + condition related to an enclosure in which the equipment resides + (ITU-T Recommendation X.733). + * QOS_ALARM: An alarm of this type is associated with + degradation in the + quality of a service (ITU-T Recommendation X.733). + * EQUIPMENT_ALARM: An alarm of this type is associated + with an equipment + fault (ITU-T Recommendation X.733). + type: string + enum: + - COMMUNICATIONS_ALARM + - PROCESSING_ERROR_ALARM + - ENVIRONMENTAL_ALARM + - QOS_ALARM + - EQUIPMENT_ALARM + probableCauses: + description: > + Match VNF alarms with a probable cause listed in this + attribute. + type: array + items: + 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 using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + subscription.get.200: + description: > + 200 OK + + The operation has completed successfully. The response body shall + contain a representation of the subscription resource. + headers: + Content-Type: + description: | + The MIME type of the body of the request. Reference: IETF RFC 7231 + schema: + type: string + minimum: 1 + maximum: 1 + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP request + has provided an invalid authorization token. + schema: + type: string + minimum: 0 + maximum: 1 + Version: + description: | + Version of the API used in the response. + schema: + type: string + minimum: 1 + maximum: 1 + content: + application/json: + schema: + description: > + This type represents a subscription related to notifications about + VNF faults. + 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 NFV-MANO functional entity faults. It + shall comply with the provisions defined in table 7.6.3.2-1. + 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: + notificationTypes: + description: > + Match particular notification types. Permitted values: * + AlarmNotification * AlarmClearedNotification * + AlarmListRebuiltNotification The permitted values of the + "notificationTypes" attribute are spelled exactly as the + names of the notification types to facilitate automated + code generation systems. + type: array + items: + type: string + enum: + - AlarmNotification + - AlarmClearedNotification + - AlarmListRebuiltNotification + perceivedSeverities: + description: > + Match VNF alarms with a perceived severity listed in this + attribute. + type: array + items: + description: > + Indicates the relative level of urgency for operator + attention. * CRITICAL: The Critical severity level + indicates that a service + affecting condition has occurred and an immediate corrective action + is required. Such a severity can be reported, for example, when a + managed object becomes totally out of service and its capability needs + to be restored (ITU-T Recommendation X.733). + * MAJOR: The Major severity level indicates that a + service affecting + condition has developed and an urgent corrective action is required. + Such a severity can be reported, for example, when there is a severe + degradation in the capability of the managed object and its full + capability needs to be restored (ITU-T Recommendation X.733). + * MINOR: The Minor severity level indicates the + existence of a + non-service affecting fault condition and that corrective action + should be taken in order to prevent a more serious (for example, + service affecting) fault. Such a severity can be reported, for + example, when the detected alarm condition is not currently degrading + the capacity of the managed object (ITU-T Recommendation X.733). + * WARNING: The Warning severity level indicates the + detection of a + potential or impending service affecting fault, before any significant + effects have been felt. Action should be taken to further diagnose (if + necessary) and correct the problem in order to prevent it from + becoming a more serious service affecting fault (ITU-T Recommendation + X.733). + * INDETERMINATE: The Indeterminate severity level + indicates that the + severity level cannot be determined (ITU-T Recommendation X.733). + * CLEARED: The Cleared severity level indicates the + clearing of one or + more previously reported alarms. This alarm clears all alarms for this + managed object that have the same Alarm type, Probable cause and + Specific problems (if given) (ITU-T Recommendation X.733). + type: string + enum: + - CRITICAL + - MAJOR + - MINOR + - WARNING + - INDETERMINATE + - CLEARED + eventTypes: + description: > + Match VNF alarms with an event type listed in this + attribute. + type: array + items: + description: > + The enumeration EventType represents those types of + events that trigger an alarm. * COMMUNICATIONS_ALARM: An + alarm of this type is associated with the + procedure and/or process required conveying information from one point + to another (ITU-T Recommendation X.733). + * PROCESSING_ERROR_ALARM: An alarm of this type is + associated with a + software or processing fault (ITU-T Recommendation X.733). + * ENVIRONMENTAL_ALARM: An alarm of this type is + associated with a + condition related to an enclosure in which the equipment resides + (ITU-T Recommendation X.733). + * QOS_ALARM: An alarm of this type is associated with + degradation in the + quality of a service (ITU-T Recommendation X.733). + * EQUIPMENT_ALARM: An alarm of this type is associated + with an equipment + fault (ITU-T Recommendation X.733). + type: string + enum: + - COMMUNICATIONS_ALARM + - PROCESSING_ERROR_ALARM + - ENVIRONMENTAL_ALARM + - QOS_ALARM + - EQUIPMENT_ALARM + probableCauses: + description: > + Match VNF alarms with a probable cause listed in this + attribute. + type: array + items: + 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 using an + absolute URI. + type: object + required: + - href + properties: + href: + description: | + String formatted according to IETF RFC 3986. + type: string + subscription.delete.204: + description: > + 204 NO CONTENT + + Shall be returned when the "Individual subscription" resource has been + deleted successfully. The response body shall be empty. + headers: + WWW-Authenticate: + description: > + Challenge if the corresponding HTTP request has not provided + authorization, or error details if the corresponding HTTP request + has provided an invalid authorization token. + schema: + type: string + minimum: 0 + maximum: 1 + Version: + description: | + Version of the API used in the response. + schema: + type: string + minimum: 1 + maximum: 1 \ No newline at end of file -- GitLab From bec6087db058e94d7c40b8f51cf7fc3cfb6f31e6 Mon Sep 17 00:00:00 2001 From: uihassan Date: Thu, 9 Jul 2020 11:59:17 +0500 Subject: [PATCH 06/22] Added Test Cases for Subscriptions.robot --- .../FaultManagement-APIKeyword.robot | 84 ++++++++++ .../Subscriptions.robot | 154 ++++++++++++++++++ .../environment/variables.txt | 4 + .../jsons/alarmModifications.json | 3 + .../jsons/fmSubscriptionRequest.json | 3 + .../schemas/FmSubscription.schema.json | 97 +++++++++++ .../schemas/FmSubscriptions.schema.json | 100 ++++++++++++ 7 files changed, 445 insertions(+) create mode 100644 SOL009/NFVMANOFaultManagement-API/Subscriptions.robot create mode 100644 SOL009/NFVMANOFaultManagement-API/jsons/alarmModifications.json create mode 100644 SOL009/NFVMANOFaultManagement-API/jsons/fmSubscriptionRequest.json create mode 100644 SOL009/NFVMANOFaultManagement-API/schemas/FmSubscription.schema.json create mode 100644 SOL009/NFVMANOFaultManagement-API/schemas/FmSubscriptions.schema.json diff --git a/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot b/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot index 9633d085f..b063a059b 100644 --- a/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot +++ b/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot @@ -166,4 +166,88 @@ DELETE Fault Management Individual Alarm Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} Delete ${apiRoot}/${apiName}/${apiMajorVersion}/alarms/${alarmId} ${outputResponse}= Output response + Set Global Variable @{response} ${outputResponse} + +POST Subscription + Log Create subscription instance by POST to ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions + Set Headers {"Accept":"${ACCEPT}"} + Set Headers {"Content-Type": "${CONTENT_TYPE}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} + ${body}= Get File jsons/fmSubscriptionRequest.json + Post ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions ${body} + ${outputResponse}= Output response + Set Global Variable @{response} ${outputResponse} + +Check Operation Occurrence Id + ${opOccId}= Get Value From Json ${response['headers']} $..Location + Should Not Be Empty ${opOccId} + +POST Subscription Duplication permitted + Log Create subscription instance by POST to ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions + Pass Execution If ${NFVMANO_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 jsons/fmSubscriptionRequest.json + Post ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions ${body} + ${outputResponse}= Output response + Set Global Variable @{response} ${outputResponse} + +POST Subscription Duplication not permitted + Log Create subscription instance by POST to ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions + Pass Execution If ${NFVMANO_DUPLICATION} == 1 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 jsons/fmSubscriptionRequest.json + Post ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions ${body} + ${outputResponse}= Output response + Set Global Variable @{response} ${outputResponse} + +GET Subscriptions + Log Get the list of active subscriptions + Set Headers {"Accept": "${ACCEPT}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"} + GET ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions + ${outputResponse}= Output response + Set Global Variable @{response} ${outputResponse} + +GET Subscriptions with 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}/${apiMajorVersion}/subscriptions?${sub_filter} + ${outputResponse}= Output response + Set Global Variable @{response} ${outputResponse} + +GET Subscriptions with Invalid filter + 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}/${apiMajorVersion}/subscriptions?${sub_filter_invalid} + ${outputResponse}= Output response + Set Global Variable @{response} ${outputResponse} + +PUT Subscriptions + log Trying to perform a PUT Subscriptions. This method should not be implemented + Set Headers {"Accept":"${ACCEPT}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} + Put ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions + ${outputResponse}= Output response + Set Global Variable @{response} ${outputResponse} + +PATCH Subscriptions + log Trying to perform a PATCH Subscriptions. This method should not be implemented + Set Headers {"Accept":"${ACCEPT}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} + Patch ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions + ${outputResponse}= Output response + Set Global Variable @{response} ${outputResponse} + +DELETE Subscriptions + log Trying to perform a DELETE Subscriptions. This method should not be implemented + Set Headers {"Accept":"${ACCEPT}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} + Delete ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions + ${outputResponse}= Output response Set Global Variable @{response} ${outputResponse} \ No newline at end of file diff --git a/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot b/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot new file mode 100644 index 000000000..2f4a25ac1 --- /dev/null +++ b/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot @@ -0,0 +1,154 @@ +*** Settings *** +Resource environment/variables.txt +Resource FaultManagement-APIKeyword.robot +Library DependencyLibrary +Library REST ${VNFM_SCHEMA}://${VNFM_HOST}:${VNFM_PORT} +Library OperatingSystem +Library JSONLibrary +Library JSONSchemaLibrary schemas/ + +*** Test Cases *** +Create a new Fault Management alarm subscription + [Documentation] Test ID:8.3.3.3.1 + ... Test title: Create a new Fault Management alarm subscription + ... Test objective: The objective is to create a new Fault management alarm subscriptions and perform a JSON schema and content validation of the returned fault management alarms subscription data structure + ... Pre-conditions: No subscription with the same filter and callbackUri exists + ... Reference: clause 7.5.5.3.1 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: subscription is created + POST Subscription + Check HTTP Response Status Code Is 201 + Check Operation Occurrence Id + Check HTTP Response Body Json Schema Is FmSubscription + + +Create a new alarm subscription - DUPLICATION + [Documentation] Test ID: 8.3.3.3.2 + ... Test title: Create a new alarm subscription - DUPLICATION + ... Test objective: The objective is to create a new subscription with the NFV-MANO allowing duplication and perform a JSON schema and content validation of the returned fault management alarms subscription data structure. + ... Pre-conditions: subscription with the same filter and callbackUri exists + ... Reference: clause 7.5.5.3.1 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: the NFV-MANO allows creating a subscription resource if another subscription resource with the same filter and callbackUri already exists + ... Post-Conditions: duplicated subscription is created + POST Subscription Duplication permitted + Check HTTP Response Status Code Is 201 + Check Operation Occurrence Id + Check HTTP Response Body Json Schema Is FmSubscription + +Create a new alarm subscription - NO DUPLICATION + [Documentation] Test ID: 8.3.3.3.3 + ... Test title: Create a new alarm subscription - NO DUPLICATION + ... Test objective: The objective is to create a new subscription with the NFV-MANO not allowing duplication and perform a JSON schema and content validation of the returned fault management alarms subscription data structure. + ... Pre-conditions: subscription with the same filter and callbackUri exists + ... Reference: clause 7.5.5.3.1 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: the NFV-MANO decides to not create a duplicate subscription resource + ... Post-Conditions: duplicated subscription is not created + POST Subscription Duplication not permitted + Check HTTP Response Status Code Is 303 + Check Operation Occurrence Id + Check HTTP Response Body Json Schema Is FmSubscription + +Retrieve a list of alarm subscriptions + [Documentation] Test ID: 8.3.3.3.4 + ... Test title: Retrieve a list of alarm subscriptions + ... Test objective: The objective is to retrieve the list of active subscriptions and perform a JSON schema and content validation of the returned fault management alarms subscription data structure. + ... Pre-conditions: none + ... Reference: clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: noe + GET Subscriptions + Check HTTP Response Status Code Is 200 + Check HTTP Response Body Json Schema Is FmSubscriptions + +Retrieve a list of alarm subscriptions with filter + [Documentation] Test ID: 8.3.3.3.5 + ... Test title: Retrieve a list of alarm subscriptions with filter + ... Test objective: The objective is to retrieve the list of active subscriptions with filter and perform a JSON schema and content validation of the returned fault management alarms subscription data structure. + ... Pre-conditions: none + ... Reference: clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + GET Subscriptions with filter + Check HTTP Response Status Code Is 200 + Check HTTP Response Body Json Schema Is FmSubscriptions + +Get information about multiple alarms as a Paged Response + [Documentation] Test ID: 8.3.3.3.6 + ... Test title: Get information about multiple alarms as a Paged Response + ... Test objective: The objective is to retrieve information about active list subscriptions as a Paged Response + ... Pre-conditions: none + ... Reference: Clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + GET Subscriptions + Check HTTP Response Status Code Is 200 + Check LINK in Header + +GET subscriptions - Bad Request Invalid attribute-based filtering parameters + [Documentation] Test ID: 8.3.3.3.7 + ... Test title: GET subscriptions - Bad Request Invalid attribute-based filtering parameters + ... Test objective: The objective is to retrieve the list of active subscriptions with Invalid attribute-based filtering parameters and perform a JSON schema and content validation of the returned problem details data structure. + ... Pre-conditions: none + ... Reference: clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + GET Subscriptions with Invalid filter + Check HTTP Response Status Code Is 400 + Check HTTP Response Body Json Schema Is ProblemDetails + + +Get information about multiple alarms - Bad Request Response too Big + [Documentation] Test ID: 8.3.3.3.8 + ... Test title: Get information about multiple alarms - Bad Request Response too Big + ... Test objective: The objective is to try to retrieve information about active list subscription to check that response is too big and perform a JSON schema and content validation of the returned problem details data structure + ... Pre-conditions: none + ... Reference: Clause clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + GET Subscriptions + Check HTTP Response Status Code Is 400 + Check HTTP Response Body Json Schema Is ProblemDetails + +PUT subscriptions - Method not implemented + [Documentation] Test ID: 8.3.3.3.9 + ... Test title:PUT subscriptions - Method not implemented + ... Test objective: The objective is to test that PUT method is not allowed to for Fault management subscriptions on VNF + ... Pre-conditions: none + ... RReference: clause 7.5.5.3.3 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + Put Subscriptions + Check HTTP Response Status Code Is 405 + +PATCH subscriptions - Method not implemented + [Documentation] Test ID: 8.3.3.3.10 + ... Test title: PATCH subscriptions - Method not implemented + ... Test objective: The objective is to test that PATCH method is not allowed to for Fault management subscriptions on VNF + ... Pre-conditions: none + ... Reference: clause 7.5.5.3.4 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + PATCH Subscriptions + Check HTTP Response Status Code Is 405 + +DELETE subscriptions - Method not implemented + [Documentation] Test ID: 8.3.3.3.11 + ... Test title: DELETE subscriptions - Method not implemented + ... Test objective: The objective is to test that DELETE method is not allowed to for Fault management subscriptions on VNF + ... Pre-conditions: none + ... Reference: clause 7.5.5.3.5 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: subscription is not deleted + DELETE Subscriptions + Check HTTP Response Status Code Is 405 \ No newline at end of file diff --git a/SOL009/NFVMANOFaultManagement-API/environment/variables.txt b/SOL009/NFVMANOFaultManagement-API/environment/variables.txt index f06277a9a..0e19218af 100644 --- a/SOL009/NFVMANOFaultManagement-API/environment/variables.txt +++ b/SOL009/NFVMANOFaultManagement-API/environment/variables.txt @@ -25,6 +25,10 @@ ${alarmId} 6fc3539c-e602-4afa-8e13-962fb5a7d81d ${Etag}= an etag ${Etag_modified}= a modified etag +${NFVMANO_DUPLICATION} 1 +${sub_filter} filter +${sub_filter_invalid} filter_invalid + diff --git a/SOL009/NFVMANOFaultManagement-API/jsons/alarmModifications.json b/SOL009/NFVMANOFaultManagement-API/jsons/alarmModifications.json new file mode 100644 index 000000000..53121e5b7 --- /dev/null +++ b/SOL009/NFVMANOFaultManagement-API/jsons/alarmModifications.json @@ -0,0 +1,3 @@ +{ + "ackState": "ACKNOWLEDGED" +} \ No newline at end of file diff --git a/SOL009/NFVMANOFaultManagement-API/jsons/fmSubscriptionRequest.json b/SOL009/NFVMANOFaultManagement-API/jsons/fmSubscriptionRequest.json new file mode 100644 index 000000000..8d91c2b81 --- /dev/null +++ b/SOL009/NFVMANOFaultManagement-API/jsons/fmSubscriptionRequest.json @@ -0,0 +1,3 @@ +{ + "callbackUri": "http://127.0.0.1/subscribe" +} \ No newline at end of file diff --git a/SOL009/NFVMANOFaultManagement-API/schemas/FmSubscription.schema.json b/SOL009/NFVMANOFaultManagement-API/schemas/FmSubscription.schema.json new file mode 100644 index 000000000..f0d8052b1 --- /dev/null +++ b/SOL009/NFVMANOFaultManagement-API/schemas/FmSubscription.schema.json @@ -0,0 +1,97 @@ +{ + "description": "This type represents a subscription related to notifications about VNF faults.\n", + "type": "object", + "required": [ + "id", + "callbackUri", + "_links" + ], + "properties": { + "id": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "filter": { + "description": "This type represents a subscription filter related to notifications about NFV-MANO functional entity faults. It shall comply with the provisions defined in table 7.6.3.2-1. At a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\n", + "type": "object", + "properties": { + "notificationTypes": { + "description": "Match particular notification types. Permitted values: * AlarmNotification * AlarmClearedNotification * AlarmListRebuiltNotification The permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the notification types to facilitate automated code generation systems.\n", + "type": "array", + "items": { + "type": "string", + "enum": [ + "AlarmNotification", + "AlarmClearedNotification", + "AlarmListRebuiltNotification" + ] + } + }, + "perceivedSeverities": { + "description": "Match VNF alarms with a perceived severity listed in this attribute.\n", + "type": "array", + "items": { + "description": "Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service\n affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting\n condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a\n non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a\n potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the\n severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or\n more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "CRITICAL", + "MAJOR", + "MINOR", + "WARNING", + "INDETERMINATE", + "CLEARED" + ] + } + }, + "eventTypes": { + "description": "Match VNF alarms with an event type listed in this attribute.\n", + "type": "array", + "items": { + "description": "The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the\n procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a\n software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a\n condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the\n quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment\n fault (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "COMMUNICATIONS_ALARM", + "PROCESSING_ERROR_ALARM", + "ENVIRONMENTAL_ALARM", + "QOS_ALARM", + "EQUIPMENT_ALARM" + ] + } + }, + "probableCauses": { + "description": "Match VNF alarms with a probable cause listed in this attribute.\n", + "type": "array", + "items": { + "type": "string" + } + } + } + }, + "callbackUri": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + }, + "_links": { + "description": "Links for this resource.\n", + "type": "object", + "required": [ + "self" + ], + "properties": { + "self": { + "description": "This type represents a link to a resource using an absolute URI.\n", + "type": "object", + "required": [ + "href" + ], + "properties": { + "href": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + } + } + } + } + } + } +} \ No newline at end of file diff --git a/SOL009/NFVMANOFaultManagement-API/schemas/FmSubscriptions.schema.json b/SOL009/NFVMANOFaultManagement-API/schemas/FmSubscriptions.schema.json new file mode 100644 index 000000000..56a8441cc --- /dev/null +++ b/SOL009/NFVMANOFaultManagement-API/schemas/FmSubscriptions.schema.json @@ -0,0 +1,100 @@ +{ + "type": "array", + "items": { + "description": "This type represents a subscription related to notifications about VNF faults.\n", + "type": "object", + "required": [ + "id", + "callbackUri", + "_links" + ], + "properties": { + "id": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "filter": { + "description": "This type represents a subscription filter related to notifications about NFV-MANO functional entity faults. It shall comply with the provisions defined in table 7.6.3.2-1. At a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\n", + "type": "object", + "properties": { + "notificationTypes": { + "description": "Match particular notification types. Permitted values: * AlarmNotification * AlarmClearedNotification * AlarmListRebuiltNotification The permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the notification types to facilitate automated code generation systems.\n", + "type": "array", + "items": { + "type": "string", + "enum": [ + "AlarmNotification", + "AlarmClearedNotification", + "AlarmListRebuiltNotification" + ] + } + }, + "perceivedSeverities": { + "description": "Match VNF alarms with a perceived severity listed in this attribute.\n", + "type": "array", + "items": { + "description": "Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service\n affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting\n condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a\n non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a\n potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the\n severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or\n more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "CRITICAL", + "MAJOR", + "MINOR", + "WARNING", + "INDETERMINATE", + "CLEARED" + ] + } + }, + "eventTypes": { + "description": "Match VNF alarms with an event type listed in this attribute.\n", + "type": "array", + "items": { + "description": "The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the\n procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a\n software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a\n condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the\n quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment\n fault (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "COMMUNICATIONS_ALARM", + "PROCESSING_ERROR_ALARM", + "ENVIRONMENTAL_ALARM", + "QOS_ALARM", + "EQUIPMENT_ALARM" + ] + } + }, + "probableCauses": { + "description": "Match VNF alarms with a probable cause listed in this attribute.\n", + "type": "array", + "items": { + "type": "string" + } + } + } + }, + "callbackUri": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + }, + "_links": { + "description": "Links for this resource.\n", + "type": "object", + "required": [ + "self" + ], + "properties": { + "self": { + "description": "This type represents a link to a resource using an absolute URI.\n", + "type": "object", + "required": [ + "href" + ], + "properties": { + "href": { + "description": "String formatted according to IETF RFC 3986.\n", + "type": "string" + } + } + } + } + } + } +} +} -- GitLab From 4ca9235db8efffd83bc0b5b449b353adaca0e8a3 Mon Sep 17 00:00:00 2001 From: uihassan Date: Thu, 9 Jul 2020 13:16:36 +0500 Subject: [PATCH 07/22] Added Test Cases for IndiviualSubscription.robot --- .../FaultManagement-APIKeyword.robot | 48 ++++++++++++- .../IndividualSubscription.robot | 69 +++++++++++++++++++ .../environment/variables.txt | 2 +- 3 files changed, 117 insertions(+), 2 deletions(-) create mode 100644 SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot diff --git a/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot b/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot index b063a059b..26a08bedc 100644 --- a/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot +++ b/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot @@ -250,4 +250,50 @@ DELETE Subscriptions Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} Delete ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions ${outputResponse}= Output response - Set Global Variable @{response} ${outputResponse} \ No newline at end of file + Set Global Variable @{response} ${outputResponse} + +POST Individual Subscription + 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}/${apiMajorVersion}/subscriptions/${subscriptionId} + ${outputResponse}= Output response + Set Global Variable @{response} ${outputResponse} + +GET 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}/${apiMajorVersion}/subscriptions/${subscriptionId} + ${outputResponse}= Output response + Set Global Variable @{response} ${outputResponse} + +PUT Individual Subscription + 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}/${apiMajorVersion}/subscriptions/${subscriptionId} + ${outputResponse}= Output response + Set Global Variable @{response} ${outputResponse} + +PATCH Individual Subscription + 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}/${apiMajorVersion}/subscriptions/${subscriptionId} + ${outputResponse}= Output response + Set Global Variable @{response} ${outputResponse} + +DELETE Individual Subscription + log Trying to perform a DELETE. + Set Headers {"Accept":"${ACCEPT}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} + Delete ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions/${subscriptionId} + ${outputResponse}= Output response + Set Global Variable @{response} ${outputResponse} + +Check Individual Subscription deleted + Set Headers {"Accept":"${ACCEPT}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} + Get ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions/${subscriptionId} + Integer response status 404 \ No newline at end of file diff --git a/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot b/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot new file mode 100644 index 000000000..8d0b713b0 --- /dev/null +++ b/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot @@ -0,0 +1,69 @@ +*** Settings *** +Resource environment/variables.txt +Resource FaultManagement-APIKeyword.robot +Library JSONLibrary +Library JSONSchemaLibrary schemas/ +Library REST ${VNFM_SCHEMA}://${VNFM_HOST}:${VNFM_PORT} + +*** Test Cases *** +Post Individual Subscription - Method not implemented + [Documentation] Test ID: 8.3.3.4.1 + ... Test title: Post Individual Subscription - Method not implemented + ... Test objective: The objective is to test that POST method is not allowed for Fault management subscription on NFV-MANO + ... Pre-conditions: none + ... Reference: clause 7.5.6.3.1 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: subscription is not created + POST Individual Subscription + Check HTTP Response Status Code Is 405 + +Get Information about an individual subscription + [Documentation] Test ID: 8.3.3.4.2 + ... Test title: Get Information about an individual subscription + ... Test objective: The objective is to read an individual subscription for NFV-MANO alarms subscribed by the client and perform a JSON schema and content validation of the returned fault management individual subscription data structure + ... Pre-conditions: The subscription with the given id exists + ... Reference: clause 7.5.6.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + GET Individual Subscription + Check HTTP Response Status Code Is 200 + Check HTTP Response Body Json Schema Is FmSubscription + +PUT an individual subscription - Method not implemented + [Documentation] Test ID: 8.3.3.4.3 + ... Test title:PUT an individual subscription - Method not implemented + ... Test objective: The objective is to test that PUT method is not allowed for Fault management individual subscription on VNF + ... Pre-conditions: none + ... Reference: clause 7.5.6.3.3 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + PUT Individual Subscription + Check HTTP Response Status Code Is 405 + +PATCH an individual subscription - Method not implemented + [Documentation] Test ID: 8.3.3.4.4 + ... Test title:PATCH an individual subscription - Method not implemented + ... Test objective: The objective is to test that PATCH method is not allowed for Fault management individual subscription on VNF + ... Pre-conditions: none + ... Reference: clause 7.5.6.3.4 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + PATCH Individual Subscription + Check HTTP Response Status Code Is 405 + +DELETE an individual subscription + [Documentation] Test ID: 8.3.3.4.5 + ... Test title:DELETE an individual subscription + ... Test objective: The objective is to test that DELETE method removes individual subscription on VNF + ... Pre-conditions: The Subsbcription already exists + ... Reference: clause 7.5.6.3.5 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: subscription is not deleted + DELETE Individual Subscription + Check HTTP Response Status Code Is 204 + Check Individual Subscription deleted diff --git a/SOL009/NFVMANOFaultManagement-API/environment/variables.txt b/SOL009/NFVMANOFaultManagement-API/environment/variables.txt index 0e19218af..a71c20af5 100644 --- a/SOL009/NFVMANOFaultManagement-API/environment/variables.txt +++ b/SOL009/NFVMANOFaultManagement-API/environment/variables.txt @@ -29,7 +29,7 @@ ${NFVMANO_DUPLICATION} 1 ${sub_filter} filter ${sub_filter_invalid} filter_invalid - +${subscriptionId} 6fc3539c-e602-4afa-8e13-962fb5a7d81f -- GitLab From 2bce77dfa3480411ce094fc0f9c51d1f0f05baab Mon Sep 17 00:00:00 2001 From: uihassan Date: Mon, 13 Jul 2020 11:19:10 +0500 Subject: [PATCH 08/22] Added Test Cases for NotificationEndpoint.robot --- .../IndividualSubscription.robot | 2 +- .../NotificationEndpoint.robot | 149 +++++++++++ .../environment/variables.txt | 15 +- .../alarmClearedNotification.schema.json | 80 ++++++ .../alarmListRebuiltNotification.schema.json | 71 +++++ .../schemas/alarmNotification.schema.json | 250 ++++++++++++++++++ 6 files changed, 564 insertions(+), 3 deletions(-) create mode 100644 SOL009/NFVMANOFaultManagement-API/NotificationEndpoint.robot create mode 100644 SOL009/NFVMANOFaultManagement-API/schemas/alarmClearedNotification.schema.json create mode 100644 SOL009/NFVMANOFaultManagement-API/schemas/alarmListRebuiltNotification.schema.json create mode 100644 SOL009/NFVMANOFaultManagement-API/schemas/alarmNotification.schema.json diff --git a/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot b/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot index 8d0b713b0..d1aa2c198 100644 --- a/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot +++ b/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot @@ -3,7 +3,7 @@ Resource environment/variables.txt Resource FaultManagement-APIKeyword.robot Library JSONLibrary Library JSONSchemaLibrary schemas/ -Library REST ${VNFM_SCHEMA}://${VNFM_HOST}:${VNFM_PORT} +Library REST ${NFVMANO_SCHEMA}://${NFVMANO_HOST}:${NFVMANO_PORT} *** Test Cases *** Post Individual Subscription - Method not implemented diff --git a/SOL009/NFVMANOFaultManagement-API/NotificationEndpoint.robot b/SOL009/NFVMANOFaultManagement-API/NotificationEndpoint.robot new file mode 100644 index 000000000..3d7cfc802 --- /dev/null +++ b/SOL009/NFVMANOFaultManagement-API/NotificationEndpoint.robot @@ -0,0 +1,149 @@ +*** Settings *** +Resource environment/variables.txt +Library MockServerLibrary +Library Process +Library OperatingSystem +Library Collections + +Suite Setup Create Sessions +Suite Teardown Terminate All Processes kill=true + +*** Test Cases *** +NFV-MANO Fault Alarm Notification + [Documentation] Test ID: 8.3.3.5.1 + ... Test title: NFV-MANO Fault Alarm Notification + ... Test objective: The objective is to test the dispatch of NFV-MANO Fault Alarm Notification when a virtualised resource within an NFV-MANO instance fails, and perform a JSON schema and content validation of the delivered notification. The action that triggers the notification under test is an explicit test step, but it is not performed by the test system. + ... Pre-conditions: A NFV-MANO instance is instantiated, and a subscription for fault alarm notifications is available. + ... Reference: clause 7.5.7.3.1 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + Trigger the fault of a virtualised resource in the NFV-MANO instance (external action) + Check Alarm Notification Http POST Request Body Json Schema Is alarmNotification + Check Alarm Notification Http POST Request Body notificationType attribute Is alarmNotification + +NFV-MANO Fault Alarm Cleared Notification + [Documentation] Test ID: 8.3.3.5.2 + ... Test title: NFV-MANO Fault Alarm Cleared Notification + ... Test objective: The objective is to test the dispatch of NFV-MANO Fault Alarm Cleared Notification when a faulty virtualised resource within an NFV-MANO instance is cleared, and perform a JSON schema and content validation of the delivered notification. The action that triggers the notification under test is an explicit test step, but it is not performed by the test system. + ... Pre-conditions: A NFV-MANO instance is instantiated, a virtualised resource is in faulty state, and a subscription for fault alarm cleared notifications is available. + ... Reference: clause 7.5.7.3.1 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + Trigger the clear of a faulty virtualised resource in the NFV-MANO instance (external action) + Check Alarm cleared Notification Http POST Request Body Json Schema Is alarmClearedNotification + Check Alarm cleared Notification Http POST Request Body notificationType attribute Is alarmClearedNotification + +NFV-MANO Fault Alarm List Rebuilt Notification + [Documentation] Test ID: 8.3.3.5.3 + ... Test title: NFV-MANO Fault Alarm List Rebuilt Notification + ... Test objective: The objective is to test the dispatch of NFV-MANO Fault Alarm List Rebuilt Notification when the NFV-MANO decides to rebuild the list of its NFV-MANO alarms, e.g. due to a corruption in the alarm storage, and perform a JSON schema and content validation of the delivered notification. The action that triggers the notification under test is an explicit test step, but it is not performed by the test system. + ... Pre-conditions: A NFV-MANO instance is instantiated, one or more virtualised resource are in faulty state, and a subscription for fault alarm list rebuilt notifications is available. + ... Reference: clause 7.5.7.3.1 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + Trigger the NFV-MANO fault alarm list rebuild in the NFVO (external action) + Check Alarm list rebuilt Notification Http POST Request Body Json Schema Is alarmListRebuiltNotification + Check Alarm list rebuilt Notification Http POST Request Body notificationType attribute Is alarmListRebuiltNotification + + +*** Keywords *** +Trigger the fault of a virtualised resource in the NFV-MANO instance (external action) + #do nothing + Log do nothing + +Trigger the clear of a faulty virtualised resource in the NFV-MANO instance (external action) + #do nothing + Log do nothing + +Trigger the NFV-MANO fault alarm list rebuild in the NFVO (external action) + #do nothing + Log do nothing + +Check Alarm List Rebuilt Notification Http POST Request Body Json Schema Is + [Arguments] ${element} + ${schema}= Get File schemas/${element}.schema.json + Configure Notification Forward ${schema} ${callback_endpoint} ${callback_endpoint_fwd} + +Check Alarm List Rebuilt Notification Http POST Request Body notificationType attribute Is + [Arguments] ${type} + Configure Notification Alarm List Rebuilt Handler ${callback_endpoint_fwd} ${type} + Wait Until Keyword Succeeds 2 min 10 sec Verify Mock Expectation ${notification_request} + Clear Requests ${callback_endpoint} + Clear Requests ${callback_endpoint_fwd} + +Check Alarm Notification Http POST Request Body Json Schema Is + [Arguments] ${element} + ${schema}= Get File schemas/${element}.schema.json + Configure Notification Forward ${schema} ${callback_endpoint} ${callback_endpoint_fwd} + +Check Alarm Notification Http POST Request Body notificationType attribute Is + [Arguments] ${type} + Configure Notification Alarm Handler ${callback_endpoint_fwd} ${type} + Wait Until Keyword Succeeds 2 min 10 sec Verify Mock Expectation ${notification_request} + Clear Requests ${callback_endpoint} + Clear Requests ${callback_endpoint_fwd} + +Check Alarm cleared Notification Http POST Request Body Json Schema Is + [Arguments] ${element} + ${schema}= Get File schemas/${element}.schema.json + Configure Notification Forward ${schema} ${callback_endpoint} ${callback_endpoint_fwd} + + +Check Alarm cleared Notification Http POST Request Body notificationType attribute Is + [Arguments] ${type} + Configure Notification Alarm Cleareance Handler ${callback_endpoint_fwd} ${type} + Wait Until Keyword Succeeds 2 min 10 sec Verify Mock Expectation ${notification_request} + Clear Requests ${callback_endpoint} + Clear Requests ${callback_endpoint_fwd} + + +Check Alarm Clerance Notification Http POST Request Body changeType attribute Is + [Arguments] ${type} + #do nothing + Log do nothing + + +Configure Notification Alarm List Rebuilt Handler + [Arguments] ${endpoint} ${type} + ${json}= evaluate {} + set to dictionary ${json} notificationType ${type} + ${BODY}= evaluate json.dumps(${json}) json + Log Creating mock request and response to handle status notification + &{notification_request}= Create Mock Request Matcher POST ${endpoint} body_type="JSON" body=${BODY} + &{notification_response}= Create Mock Response headers="Content-Type: application/json" status_code=204 + Create Mock Expectation ${notification_request} ${notification_response} + +Configure Notification Alarm Handler + [Arguments] ${endpoint} ${type} + ${json}= evaluate {} + set to dictionary ${json} notificationType ${type} + ${BODY}= evaluate json.dumps(${json}) json + Log Creating mock request and response to handle status notification + &{notification_request}= Create Mock Request Matcher POST ${endpoint} body_type="JSON" body=${BODY} + &{notification_response}= Create Mock Response headers="Content-Type: application/json" status_code=204 + Create Mock Expectation ${notification_request} ${notification_response} + +Configure Notification Alarm Cleareance Handler + [Arguments] ${endpoint} ${type} + ${json}= evaluate {} + set to dictionary ${json} notificationType ${type} + ${BODY}= evaluate json.dumps(${json}) json + Log Creating mock request and response to handle status notification + &{notification_request}= Create Mock Request Matcher POST ${endpoint} body_type="JSON" body=${BODY} + &{notification_response}= Create Mock Response headers="Content-Type: application/json" status_code=204 + Create Mock Expectation ${notification_request} ${notification_response} + +Configure Notification Forward + [Arguments] ${schema} ${endpoint} ${endpoint_fwd} + Log Creating mock Http POST forward to handle ${schema} + &{notification_tmp}= Create Mock Request Matcher POST ${endpoint} body_type="JSON_SCHEMA" body=${schema} + &{notification_fwd}= Create Mock Http Forward ${endpoint_fwd} + Create Mock Expectation With Http Forward ${notification_tmp} ${notification_fwd} + +Create Sessions + Start Process java -jar ../../bin/mockserver-netty-5.5.0-jar-with-dependencies.jar -serverPort ${callback_port} alias=mockInstance + Wait For Process handle=mockInstance timeout=5s on_timeout=continue + Create Mock Session ${callback_uri}:${callback_port} diff --git a/SOL009/NFVMANOFaultManagement-API/environment/variables.txt b/SOL009/NFVMANOFaultManagement-API/environment/variables.txt index a71c20af5..eee387083 100644 --- a/SOL009/NFVMANOFaultManagement-API/environment/variables.txt +++ b/SOL009/NFVMANOFaultManagement-API/environment/variables.txt @@ -31,5 +31,16 @@ ${sub_filter_invalid} filter_invalid ${subscriptionId} 6fc3539c-e602-4afa-8e13-962fb5a7d81f - - +${callback_uri} http://localhost +${callback_port} 9091 +${callback_endpoint} /endpoint +${callback_endpoint_fwd} /endpoint/check +${callback_endpoint_error} /endpoint_404 +${sleep_interval} 20s +${total_polling_time} 2 min +${polling_interval} 10 sec + +${notification_request} [] +${notification_response} [] + +${MOCK_SERVER_JAR} ../../../bin/mockserver-netty-5.5.0-jar-with-dependencies.jar \ No newline at end of file diff --git a/SOL009/NFVMANOFaultManagement-API/schemas/alarmClearedNotification.schema.json b/SOL009/NFVMANOFaultManagement-API/schemas/alarmClearedNotification.schema.json new file mode 100644 index 000000000..08131723d --- /dev/null +++ b/SOL009/NFVMANOFaultManagement-API/schemas/alarmClearedNotification.schema.json @@ -0,0 +1,80 @@ +{ + "description": "This type represents an alarm cleared notification about VNF faults. The notification shall be triggered by the VNFM when an alarm has been cleared.\n", + "type": "object", + "required": [ + "id", + "notificationType", + "subscriptionId", + "timeStamp", + "alarmId", + "alarmClearedTime", + "_links" + ], + "properties": { + "id": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "notificationType": { + "description": "Discriminator for the different notification types. Shall be set to \"AlarmClearedNotification\" for this notification type.\n", + "type": "string", + "enum": [ + "AlarmClearedNotification" + ] + }, + "subscriptionId": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "timeStamp": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "alarmId": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "alarmClearedTime": { + "description": "The time stamp indicating when the alarm was cleared.\n" + }, + "_links": { + "description": "Links to resources related to this notification.\n", + "type": "object", + "required": [ + "subscription", + "alarm" + ], + "properties": { + "subscription": { + "description": "This type represents a link to a resource.\n", + "type": "object", + "required": [ + "href" + ], + "properties": { + "href": { + "description": "URI of the referenced resource.\n", + "type": "string", + "format": "url" + } + } + }, + "alarm": { + "description": "This type represents a link to a resource.\n", + "type": "object", + "required": [ + "href" + ], + "properties": { + "href": { + "description": "URI of the referenced resource.\n", + "type": "string", + "format": "url" + } + } + } + } + } + } +} \ No newline at end of file diff --git a/SOL009/NFVMANOFaultManagement-API/schemas/alarmListRebuiltNotification.schema.json b/SOL009/NFVMANOFaultManagement-API/schemas/alarmListRebuiltNotification.schema.json new file mode 100644 index 000000000..bfe018df8 --- /dev/null +++ b/SOL009/NFVMANOFaultManagement-API/schemas/alarmListRebuiltNotification.schema.json @@ -0,0 +1,71 @@ +{ + "description": "This type represents a notification that the alarm list has been rebuilt, e.g. if the VNFM detects its storage holding the alarm list is corrupted. The notification shall be triggered by the VNFM when the alarm list has been rebuilt.\n", + "type": "object", + "required": [ + "id", + "notificationType", + "subscriptionId", + "timeStamp", + "_links" + ], + "properties": { + "id": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "notificationType": { + "description": "Discriminator for the different notification types. Shall be set to \"AlarmListRebuiltNotification\" for this notification type.\n", + "type": "string", + "enum": [ + "AlarmListRebuiltNotification" + ] + }, + "subscriptionId": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "timeStamp": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "_links": { + "description": "Links to resources related to this notification.\n", + "type": "object", + "required": [ + "subscription", + "alarms" + ], + "properties": { + "subscription": { + "description": "This type represents a link to a resource.\n", + "type": "object", + "required": [ + "href" + ], + "properties": { + "href": { + "description": "URI of the referenced resource.\n", + "type": "string", + "format": "url" + } + } + }, + "alarms": { + "description": "This type represents a link to a resource.\n", + "type": "object", + "required": [ + "href" + ], + "properties": { + "href": { + "description": "URI of the referenced resource.\n", + "type": "string", + "format": "url" + } + } + } + } + } + } +} \ No newline at end of file diff --git a/SOL009/NFVMANOFaultManagement-API/schemas/alarmNotification.schema.json b/SOL009/NFVMANOFaultManagement-API/schemas/alarmNotification.schema.json new file mode 100644 index 000000000..1d31e7e34 --- /dev/null +++ b/SOL009/NFVMANOFaultManagement-API/schemas/alarmNotification.schema.json @@ -0,0 +1,250 @@ +{ + "name": "AlarmNotification", + "description": "Information of a VNF alarm.\n", + "in": "body", + "required": true, + "schema": { + "description": "This type represents an alarm notification about VNF faults. This notification shall be triggered by the VNFM when: * An alarm has been created. * An alarm has been updated, e.g. if the severity of the alarm has changed.\n", + "type": "object", + "required": [ + "id", + "notificationType", + "subscriptionId", + "timeStamp", + "alarm", + "_links" + ], + "properties": { + "id": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "notificationType": { + "description": "Discriminator for the different notification types. Shall be set to \"AlarmNotification\" for this notification type.\n", + "type": "string", + "enum": [ + "AlarmNotification" + ] + }, + "subscriptionId": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "timeStamp": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "alarm": { + "description": "The alarm data type encapsulates information about an alarm.\n", + "type": "object", + "required": [ + "id", + "managedObjectId", + "rootCauseFaultyResource", + "alarmRaisedTime", + "ackState", + "perceivedSeverity", + "eventTime", + "eventType", + "probableCause", + "isRootCause", + "_links" + ], + "properties": { + "id": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "managedObjectId": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "rootCauseFaultyResource": { + "description": "This type represents the faulty virtual resources that have a negative impact on a VNF.\n", + "type": "object", + "required": [ + "faultyResource", + "faultyResourceType" + ], + "properties": { + "faultyResource": { + "required": [ + "vimConnectionId", + "resourceId" + ], + "type": "object", + "description": "This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.\n", + "properties": { + "vimConnectionId": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "resourceProviderId": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + }, + "resourceId": { + "description": "An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.\n", + "type": "string" + }, + "vimLevelResourceType": { + "description": "Type of the resource in the scope of the VIM or the resource provider.\n", + "type": "string" + } + } + }, + "faultyResourceType": { + "description": "The enumeration FaultyResourceType represents those types of faulty resource.\n", + "type": "string", + "enum": [ + "COMPUTE", + "STORAGE", + "NETWORK" + ] + } + } + }, + "alarmRaisedTime": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "alarmChangedTime": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "alarmClearedTime": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "ackState": { + "description": "Acknowledgement state of the alarm. Permitted values: * UNACKNOWLEDGED * ACKNOWLEDGED.\n", + "type": "string", + "enum": [ + "UNACKNOWLEDGED", + "ACKNOWLEDGED" + ] + }, + "perceivedSeverity": { + "description": "Indicates the relative level of urgency for operator attention. * CRITICAL: The Critical severity level indicates that a service affecting condition has occurred and an immediate corrective action\n is required. Such a severity can be reported, for example, when a\n managed object becomes totally out of service and its capability needs\n to be restored (ITU-T Recommendation X.733).\n* MAJOR: The Major severity level indicates that a service affecting condition has developed and an urgent corrective action is required.\n Such a severity can be reported, for example, when there is a severe\n degradation in the capability of the managed object and its full\n capability needs to be restored (ITU-T Recommendation X.733).\n* MINOR: The Minor severity level indicates the existence of a non-service affecting fault condition and that corrective action\n should be taken in order to prevent a more serious (for example,\n service affecting) fault. Such a severity can be reported, for\n example, when the detected alarm condition is not currently degrading\n the capacity of the managed object (ITU-T Recommendation X.733).\n* WARNING: The Warning severity level indicates the detection of a potential or impending service affecting fault, before any significant\n effects have been felt. Action should be taken to further diagnose (if\n necessary) and correct the problem in order to prevent it from\n becoming a more serious service affecting fault (ITU-T Recommendation\n X.733).\n* INDETERMINATE: The Indeterminate severity level indicates that the severity level cannot be determined (ITU-T Recommendation X.733).\n* CLEARED: The Cleared severity level indicates the clearing of one or more previously reported alarms. This alarm clears all alarms for this\n managed object that have the same Alarm type, Probable cause and\n Specific problems (if given) (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "CRITICAL", + "MAJOR", + "MINOR", + "WARNING", + "INDETERMINATE", + "CLEARED" + ] + }, + "eventTime": { + "description": "Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n", + "type": "string", + "format": "date-time" + }, + "eventType": { + "description": "The enumeration EventType represents those types of events that trigger an alarm. * COMMUNICATIONS_ALARM: An alarm of this type is associated with the procedure and/or process required conveying information from one point\n to another (ITU-T Recommendation X.733).\n* PROCESSING_ERROR_ALARM: An alarm of this type is associated with a software or processing fault (ITU-T Recommendation X.733).\n* ENVIRONMENTAL_ALARM: An alarm of this type is associated with a condition related to an enclosure in which the equipment resides\n (ITU-T Recommendation X.733).\n* QOS_ALARM: An alarm of this type is associated with degradation in the quality of a service (ITU-T Recommendation X.733).\n* EQUIPMENT_ALARM: An alarm of this type is associated with an equipment fault (ITU-T Recommendation X.733).\n", + "type": "string", + "enum": [ + "COMMUNICATIONS_ALARM", + "PROCESSING_ERROR_ALARM", + "ENVIRONMENTAL_ALARM", + "QOS_ALARM", + "EQUIPMENT_ALARM" + ] + }, + "faultType": { + "description": "Additional information to clarify the type of the fault.\n", + "type": "string" + }, + "probableCause": { + "description": "Information about the probable cause of the fault.\n", + "type": "string" + }, + "isRootCause": { + "description": "Attribute indicating if this fault is the root for other correlated alarms. If TRUE, then the alarms listed in the attribute CorrelatedAlarmId are caused by this fault.\n", + "type": "boolean" + }, + "correlatedAlarmIds": { + "description": "List of identifiers of other alarms correlated to this fault.\n", + "type": "array", + "items": { + "description": "An identifier with the intention of being globally unique.\n", + "type": "string" + } + }, + "faultDetails": { + "description": "Provides additional information about the fault.\n", + "type": "array", + "items": { + "type": "string" + } + }, + "_links": { + "description": "Links for this resource.\n", + "type": "object", + "required": [ + "self" + ], + "properties": { + "self": { + "description": "This type represents a link to a resource.\n", + "type": "object", + "required": [ + "href" + ], + "properties": { + "href": { + "description": "URI of the referenced resource.\n", + "type": "string", + "format": "url" + } + } + }, + "objectInstance": { + "description": "This type represents a link to a resource.\n", + "type": "object", + "required": [ + "href" + ], + "properties": { + "href": { + "description": "URI of the referenced resource.\n", + "type": "string", + "format": "url" + } + } + } + } + } + } + }, + "_links": { + "description": "Links to resources related to this notification.\n", + "type": "object", + "required": [ + "subscription" + ], + "properties": { + "subscription": { + "description": "This type represents a link to a resource.\n", + "type": "object", + "required": [ + "href" + ], + "properties": { + "href": { + "description": "URI of the referenced resource.\n", + "type": "string", + "format": "url" + } + } + } + } + } + } + } +} \ No newline at end of file -- GitLab From fe0c4e35bb71ef9722133cac4c34777397550eff Mon Sep 17 00:00:00 2001 From: uihassan Date: Mon, 17 Aug 2020 12:25:22 +0500 Subject: [PATCH 09/22] Added Test Cases for ApiVersion.robot --- .../ApiVersion.robot | 211 ++++++++++++++++++ 1 file changed, 211 insertions(+) create mode 100644 SOL009/NFVMANOFaultManagement-API/ApiVersion.robot diff --git a/SOL009/NFVMANOFaultManagement-API/ApiVersion.robot b/SOL009/NFVMANOFaultManagement-API/ApiVersion.robot new file mode 100644 index 000000000..a02570f36 --- /dev/null +++ b/SOL009/NFVMANOFaultManagement-API/ApiVersion.robot @@ -0,0 +1,211 @@ +*** Settings *** +Resource environment/variables.txt +Library REST ${NFVMANO_SCHEMA}://${NFVMANO_HOST}:${NFVMANO_PORT} ssl_verify=false +Library DependencyLibrary +Library JSONLibrary +Library JSONSchemaLibrary schemas/ + +*** Test Cases *** +POST API Version - Method not implemented + [Documentation] Test ID: 8.3.3.6.1 + ... Test title: POST API version - Method not implemented + ... Test objective: The objective is to test that POST method is not implemented + ... Pre-conditions: none + ... Reference: Clause 9.3.3.3.1 - ETSI GS NFV-SOL 013 v2.7.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + POST API Version + Check HTTP Response Status Code Is 405 + +GET API Version + [Documentation] Test ID: 8.3.3.6.2 + ... Test title: GET API Version + ... Test objective: The objective is to test that GET method successfully return ApiVersionInformation + ... Pre-conditions: none + ... Reference: Clause 9.3.3.3.2 - ETSI GS NFV-SOL 013 v2.7.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + GET API Version + Check HTTP Response Status Code Is 200 + Check HTTP Response Body Json Schema Is ApiVersionInformation + +PUT API Version - Method not implemented + [Documentation] Test ID: 8.3.3.6.3 + ... Test title: PUT API Version - Method not implemented + ... Test objective: The objective is to test that PUT method is not implemented + ... Pre-conditions: none + ... Reference: Clause 9.3.3.3.3 - ETSI GS NFV-SOL 013 v2.7.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + PUT API Version + Check HTTP Response Status Code Is 405 + +PATCH API Version - Method not implemented + [Documentation] Test ID: 8.3.3.6.4 + ... Test title: PATCH API Version - Method not implemented + ... Test objective: The objective is to test that PATCH method is not implemented + ... Pre-conditions: none + ... Reference: Clause 9.3.3.3.4 - ETSI GS NFV-SOL 013 v2.7.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + PATCH API Version + Check HTTP Response Status Code Is 405 + +DELETE API Version - Method not implemented + [Documentation] Test ID: 8.3.3.6.5 + ... Test title: DELETE API Version - Method not implemented + ... Test objective: The objective is to test that DELETE method is not implemented + ... Pre-conditions: none + ... Reference: Clause 9.3.3.3.5 - ETSI GS NFV-SOL 013 v2.7.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + DELETE API Version + Check HTTP Response Status Code Is 405 + +POST API Version with apiMajorVerion - Method not implemented + [Documentation] Test ID: 8.3.3.6.6 + ... Test title: POST API version with apiMajorVerion - Method not implemented + ... Test objective: The objective is to test that POST method is not implemented + ... Pre-conditions: none + ... Reference: Clause 9.3.3.3.1 - ETSI GS NFV-SOL 013 v2.7.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + POST API Version + Check HTTP Response Status Code Is 405 + +GET API Version with apiMajorVerion + [Documentation] Test ID: 8.3.3.6.7 + ... Test title: GET API Version with apiMajorVerion + ... Test objective: The objective is to test that GET method successfully return ApiVersionInformation + ... Pre-conditions: none + ... Reference: Clause 9.3.3.3.2 - ETSI GS NFV-SOL 013 v2.7.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + GET API Version + Check HTTP Response Status Code Is 200 + Check HTTP Response Body Json Schema Is ApiVersionInformation + +PUT API Version with apiMajorVerion - Method not implemented + [Documentation] Test ID: 8.3.3.6.8 + ... Test title: PUT API Version with apiMajorVerion - Method not implemented + ... Test objective: The objective is to test that PUT method is not implemented + ... Pre-conditions: none + ... Reference: Clause 9.3.3.3.3 - ETSI GS NFV-SOL 013 v2.7.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + PUT API Version + Check HTTP Response Status Code Is 405 + +PATCH API Version with apiMajorVerion - Method not implemented + [Documentation] Test ID: 8.3.3.6.9 + ... Test title: PATCH API Version with apiMajorVerion - Method not implemented + ... Test objective: The objective is to test that PATCH method is not implemented + ... Pre-conditions: none + ... Reference: Clause 9.3.3.3.4 - ETSI GS NFV-SOL 013 v2.7.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + PATCH API Version + Check HTTP Response Status Code Is 405 + +DELETE API Version with apiMajorVerion - Method not implemented + [Documentation] Test ID: 8.3.3.6.10 + ... Test title: DELETE API Version with apiMajorVerion - Method not implemented + ... Test objective: The objective is to test that DELETE method is not implemented + ... Pre-conditions: none + ... Reference: Clause 9.3.3.3.5 - ETSI GS NFV-SOL 013 v2.7.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + DELETE API Version + Check HTTP Response Status Code Is 405 + +*** Keywords *** +POST API Version + Set Headers {"Accept":"${ACCEPT_JSON}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} + Post ${apiRoot}/${apiName}/api_version + ${outputResponse}= Output response + Set Global Variable ${response} ${outputResponse} + +GET API Version + Set Headers {"Accept":"${ACCEPT_JSON}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} + Get ${apiRoot}/${apiName}/api_version + ${outputResponse}= Output response + Set Global Variable ${response} ${outputResponse} + +PUT API Version + Set Headers {"Accept":"${ACCEPT_JSON}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} + Put ${apiRoot}/${apiName}/api_version + ${outputResponse}= Output response + Set Global Variable ${response} ${outputResponse} + +PATCH API Version + Set Headers {"Accept":"${ACCEPT_JSON}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} + Patch ${apiRoot}/${apiName}/api_version + ${outputResponse}= Output response + Set Global Variable ${response} ${outputResponse} + +DELETE API Version + Set Headers {"Accept":"${ACCEPT_JSON}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} + Delete ${apiRoot}/${apiName}/api_version + ${outputResponse}= Output response + Set Global Variable ${response} ${outputResponse} + +POST API Version with apiMajorVersion + Set Headers {"Accept":"${ACCEPT_JSON}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} + Post ${apiRoot}/${apiName}/${apiMajorVersion} /api_version + ${outputResponse}= Output response + Set Global Variable ${response} ${outputResponse} + +GET API Version with apiMajorVersion + Set Headers {"Accept":"${ACCEPT_JSON}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} + Get ${apiRoot}/${apiName}/${apiMajorVersion} /api_version + ${outputResponse}= Output response + Set Global Variable ${response} ${outputResponse} + +PUT API Version with apiMajorVersion + Set Headers {"Accept":"${ACCEPT_JSON}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} + Put ${apiRoot}/${apiName}/${apiMajorVersion} /api_version + ${outputResponse}= Output response + Set Global Variable ${response} ${outputResponse} + +PATCH API Version with apiMajorVersion + Set Headers {"Accept":"${ACCEPT_JSON}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} + Patch ${apiRoot}/${apiName}/${apiMajorVersion} /api_version + ${outputResponse}= Output response + Set Global Variable ${response} ${outputResponse} + +DELETE API Version with apiMajorVersion + Set Headers {"Accept":"${ACCEPT_JSON}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} + Delete ${apiRoot}/${apiName}/${apiMajorVersion} /api_version + ${outputResponse}= Output response + Set Global Variable ${response} ${outputResponse} + +Check HTTP Response Status Code Is + [Arguments] ${expected_status} + Should Be Equal As Strings ${response['status']} ${expected_status} + Log Status code validated + +Check HTTP Response Body Json Schema Is + [Arguments] ${input} + ${schema} = Catenate ${input} .schema.json + Validate Json ${schema} ${response['body']} + Log Json Schema Validation OK -- GitLab From af04d504ca6543b9e3686461a7f5911ca1ae225c Mon Sep 17 00:00:00 2001 From: uihassan Date: Wed, 19 Aug 2020 14:15:57 +0500 Subject: [PATCH 10/22] fixed issues --- .../NFVMANOFaultManagement-API/Alarms.robot | 10 ++++----- .../FaultManagement-APIKeyword.robot | 22 +++++++++++++------ .../IndividualAlarm.robot | 22 +++++++++---------- .../IndividualSubscription.robot | 8 +++---- .../NotificationEndpoint.robot | 4 ++-- .../Subscriptions.robot | 12 +++++----- 6 files changed, 42 insertions(+), 36 deletions(-) diff --git a/SOL009/NFVMANOFaultManagement-API/Alarms.robot b/SOL009/NFVMANOFaultManagement-API/Alarms.robot index 85e1dc22a..f9ee94c8a 100644 --- a/SOL009/NFVMANOFaultManagement-API/Alarms.robot +++ b/SOL009/NFVMANOFaultManagement-API/Alarms.robot @@ -11,7 +11,7 @@ Library OperatingSystem POST Alarms - Method not implemented [Documentation] Test ID: 8.3.3.1.1 ... Test title: POST Alarms - Method not implemented - ... Test objective: The objective is to test that Post method is not allowed to create Fault management alarms on NFV-MANO + ... Test objective: The objective is to test that Post method is not allowed to create fault management alarms on NFV-MANO ... Pre-conditions: none ... Reference: clause 7.5.3.3.1 - ETSI GS NFV-SOL 009 [5] V3.3.1 ... Config ID: Config_prod_NFV-MANO @@ -63,7 +63,7 @@ Get information about multiple alarms Bad Request Invalid attribute-based filter Get information about multiple alarms as a Paged Response [Documentation] Test ID: 8.3.3.1.5 ... Test title: Get information about multiple alarms as a Paged Response - ... Test objective: The objective is to retrieve information about the alarm list as a Paged Response + ... Test objective: The objective is to retrieve information about the alarm list as a Paged Response. ... Pre-conditions: none ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 ... Config ID: Config_prod_NFV-MANO @@ -89,7 +89,7 @@ Get information about multiple alarms - Bad Request Response too Big PUT Alarms - Method not implemented [Documentation] Test ID: 8.3.3.1.7 ... Test title: PUT Alarms - Method not implemented - ... Test objective: The objective is to test that PUT method is not allowed to for Fault management alarms on NFV-MANO + ... Test objective: The objective is to test that PUT method is not allowed to modify fault management alarms on NFV-MANO. ... Pre-conditions: none ... Reference: clause 7.5.3.3.3 - ETSI GS NFV-SOL 009 [5] V3.3.1 ... Config ID: Config_prod_NFV-MANO @@ -101,7 +101,7 @@ PUT Alarms - Method not implemented PATCH Alarms - Method not implemented [Documentation] Test ID: 8.3.3.1.8 ... Test title: PATCH Alarms - Method not implemented - ... Test objective: The objective is to test that PATCH method is not allowed to for Fault management alarms on NFV-MANO + ... Test objective: The objective is to test that PATCH method is not allowed to modify fault management alarms on NFV-MANO. ... Pre-conditions: none ... Reference: clause 7.5.3.3.4 - ETSI GS NFV-SOL 009 [5] V3.3.1 ... Config ID: Config_prod_NFV-MANO @@ -113,7 +113,7 @@ PATCH Alarms - Method not implemented DELETE Alarms - Method not implemented [Documentation] Test ID: 8.3.3.1.9 ... Test title: POST Alarms - Method not implemented - ... Test objective: The objective is to test that DELETE method is not allowed for Fault management alarms on NFV-MANO + ... Test objective: The objective is to test that DELETE method is not allowed for fault management alarms on NFV-MANO ... Pre-conditions: none ... Reference: clause 7.5.3.3.5 - ETSI GS NFV-SOL 009 [5] V3.3.1 ... Config ID: Config_prod_NFV-MANO diff --git a/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot b/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot index 26a08bedc..75b547369 100644 --- a/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot +++ b/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot @@ -28,7 +28,7 @@ Check HTTP Response Status Code Is Log Status code validated GET Fault Management Alarms - Log Query NFVO The GET method queries information about multiple alarms. + Log Query NFV-MANO The GET method queries information about multiple alarms. Set Headers {"Accept":"${ACCEPT}"} Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} Log Execute Query @@ -43,7 +43,7 @@ Check HTTP Response Body Json Schema Is Log Json Schema Validation OK GET Fault Management Alarms With Filters - Log Query NFVO The GET method queries information about multiple alarms with filters. + Log Query NFV-MANO The GET method queries information about multiple alarms with filters. Set Headers {"Accept":"${ACCEPT}"} Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} Log Execute Query @@ -52,7 +52,7 @@ GET Fault Management Alarms With Filters Set Global Variable @{response} ${outputResponse} GET Fault Management Alarms With Invalid Filters - Log Query NFVO The GET method queries information about multiple alarms with filters. + Log Query NFV-MANO The GET method queries information about multiple alarms with filters. Set Headers {"Accept":"${ACCEPT}"} Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} Log Execute Query @@ -103,7 +103,7 @@ Send POST request for fault management Individual Alarm Set Global Variable @{response} ${outputResponse} GET Fault Management Individual Alarm - Log Query VNF The GET method queries information about an alarm. + Log Query NFV-MANO The GET method queries information about an alarm. Set Headers {"Accept":"${ACCEPT}"} Set Headers {"Content-Type": "${CONTENT_TYPE}"} Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} @@ -122,7 +122,7 @@ PUT Fault Management Individual Alarm ${outputResponse}= Output response Set Global Variable @{response} ${outputResponse} -Check Postcondition fault management individual alarm Exists +Check Postcondition fault management individual alarm exists Log Checking that individual alarm exists GET Fault Management Individual Alarm Check HTTP Response Status Code Is 200 @@ -139,7 +139,7 @@ PATCH Fault Management Individual Alarm Set Global Variable @{response} ${outputResponse} PATCH Fault Management Individual Alarm - precondition failed - log Trying to perform a PATCH. This method modifies an individual alarm resource + log Trying to perform a PATCH. This method fail to modifies an individual alarm resource Set Headers {"Accept":"${ACCEPT}"} Set Headers {"Content-Type": "${CONTENT_TYPE_PATCH}"} Set Headers {"If-Match": "${original_etag[0]}"} @@ -150,7 +150,7 @@ PATCH Fault Management Individual Alarm - precondition failed Set Global Variable @{response} ${outputResponse} PATCH Fault Management Individual Alarm Conflict - log Trying to perform a PATCH. This method modifies an individual alarm resource + log Trying to perform a PATCH. This method fail to modifies an individual alarm resource Set Headers {"Accept":"${ACCEPT}"} Set Headers {"Content-Type": "${CONTENT_TYPE_PATCH}"} Set Headers {"If-Match": "${Etag}"} @@ -182,6 +182,14 @@ Check Operation Occurrence Id ${opOccId}= Get Value From Json ${response['headers']} $..Location Should Not Be Empty ${opOccId} +Check PostCondition Subscription is created + 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}/${apiMajorVersion}/subscriptions/${response['body']['id']} + ${outputResponse}= Output response + Set Global Variable @{response} ${outputResponse} + POST Subscription Duplication permitted Log Create subscription instance by POST to ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions Pass Execution If ${NFVMANO_DUPLICATION} == 0 NVFO is not permitting duplication. Skipping the test diff --git a/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot b/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot index ab533b017..23e3d369e 100644 --- a/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot +++ b/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot @@ -13,7 +13,7 @@ Library DependencyLibrary POST Alarm - Method not implemented [Documentation] Test ID: 8.3.3.2.1 ... Test title: POST Alarm - Method not implemented - ... Test objective: The objective is to test that Post method is not allowed to create Fault management individual alarm on NFV-MANO + ... Test objective: The objective is to test that Post method is not allowed to create fault management individual alarm on NFV-MANO ... Pre-conditions: none ... Reference: clause 7.5.4.3.1 - ETSI GS NFV-SOL 009 [5] V3.3.1 ... Config ID: Config_prod_NFV-MANO @@ -38,7 +38,7 @@ Get information about an fault management individual alarm PUT Alarm - Method not implemented [Documentation] Test ID: 8.3.3.2.3 ... Test title: PUT Alarm - Method not implemented - ... Test objective: he objective is to test that PUT method is not allowed to for Fault management individual alarm on NFV-MANO + ... Test objective: he objective is to test that PUT method is not allowed to for fault management individual alarm on NFV-MANO ... Pre-conditions: The related alarm exists ... Reference: clause 7.5.4.3.3 - ETSI GS NFV-SOL 009 [5] V3.3.1 ... Config ID: Config_prod_NFV-MANO @@ -55,8 +55,7 @@ PATCH Fault Management Individual Alarm ... Reference: clause 7.5.4.3.4 - ETSI GS NFV-SOL 009 [5] V3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none - ... Post-Conditions: none - Check Postcondition fault management individual alarm Exists + ... Post-Conditions: Alarm is modified. PATCH Fault Management Individual Alarm Check HTTP Response Status Code Is 200 Check HTTP Response Body Json Schema Is AlarmModification @@ -69,11 +68,11 @@ Modify an individual alarm resource - Precondition failed ... Reference: clause 7.5.4.3.4 - ETSI GS NFV-SOL 009 [5] V3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none - ... Post-Conditions: none - Check Postcondition fault management individual alarm Exists + ... Post-Conditions: Alarm is not modified. PATCH Fault Management Individual Alarm - precondition failed Check HTTP Response Status Code Is 409 Check HTTP Response Body Json Schema Is ProblemDetails + Check Postcondition fault management individual alarm exists Modify an individual alarm resource - Conflict [Documentation] Test ID: 8.3.3.2.6 @@ -83,22 +82,21 @@ Modify an individual alarm resource - Conflict ... Reference: clause 7.5.4.3.4 - ETSI GS NFV-SOL 009 [5] V3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none - ... Post-Conditions: none - Depends On Test PATCH Fault Management Individual Alarm - Check Postcondition fault management individual alarm Exists + ... Post-Conditions: Alarm is not modified. PATCH Fault Management Individual Alarm Conflict Check HTTP Response Status Code Is 412 Check HTTP Response Body Json Schema Is ProblemDetails + Check Postcondition fault management individual alarm exists DELETE Alarm - Method not implemented [Documentation] Test ID: 8.3.3.2.7 ... Test title: DELETE Alarm - Method not implemented - ... Test objective: The objective is to test that DELETE method is not allowed to for Fault management individual alarm on NFV-MANO - ... Pre-conditions: nona + ... Test objective: The objective is to test that DELETE method is not allowed to delete fault management individual alarm on NFV-MANO. + ... Pre-conditions: none ... Reference: clause 7.5.4.3.5 - ETSI GS NFV-SOL 009 [5] V3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: The individual alarm still exists DELETE Fault Management Individual Alarm Check HTTP Response Status Code Is 405 - Check Postcondition fault management individual alarm Exists \ No newline at end of file + Check Postcondition fault management individual alarm exists \ No newline at end of file diff --git a/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot b/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot index d1aa2c198..470d86a23 100644 --- a/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot +++ b/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot @@ -9,7 +9,7 @@ Library REST ${NFVMANO_SCHEMA}://${NFVMANO_HOST}:${NFVMANO_PORT} Post Individual Subscription - Method not implemented [Documentation] Test ID: 8.3.3.4.1 ... Test title: Post Individual Subscription - Method not implemented - ... Test objective: The objective is to test that POST method is not allowed for Fault management subscription on NFV-MANO + ... Test objective: The objective is to test that POST method is not allowed for fault management subscription on NFV-MANO ... Pre-conditions: none ... Reference: clause 7.5.6.3.1 - ETSI GS NFV-SOL 009 [5] v3.3.1 ... Config ID: Config_prod_NFV-MANO @@ -21,7 +21,7 @@ Post Individual Subscription - Method not implemented Get Information about an individual subscription [Documentation] Test ID: 8.3.3.4.2 ... Test title: Get Information about an individual subscription - ... Test objective: The objective is to read an individual subscription for NFV-MANO alarms subscribed by the client and perform a JSON schema and content validation of the returned fault management individual subscription data structure + ... Test objective: The objective is to read an individual subscription from NFV-MANO alarms subscribed by the client and perform a JSON schema and content validation of the returned fault management individual subscription data structure ... Pre-conditions: The subscription with the given id exists ... Reference: clause 7.5.6.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 ... Config ID: Config_prod_NFV-MANO @@ -34,7 +34,7 @@ Get Information about an individual subscription PUT an individual subscription - Method not implemented [Documentation] Test ID: 8.3.3.4.3 ... Test title:PUT an individual subscription - Method not implemented - ... Test objective: The objective is to test that PUT method is not allowed for Fault management individual subscription on VNF + ... Test objective: The objective is to test that PUT method is not allowed for fault management individual subscription on VNF ... Pre-conditions: none ... Reference: clause 7.5.6.3.3 - ETSI GS NFV-SOL 009 [5] v3.3.1 ... Config ID: Config_prod_NFV-MANO @@ -46,7 +46,7 @@ PUT an individual subscription - Method not implemented PATCH an individual subscription - Method not implemented [Documentation] Test ID: 8.3.3.4.4 ... Test title:PATCH an individual subscription - Method not implemented - ... Test objective: The objective is to test that PATCH method is not allowed for Fault management individual subscription on VNF + ... Test objective: The objective is to test that PATCH method is not allowed for fault management individual subscription on VNF ... Pre-conditions: none ... Reference: clause 7.5.6.3.4 - ETSI GS NFV-SOL 009 [5] v3.3.1 ... Config ID: Config_prod_NFV-MANO diff --git a/SOL009/NFVMANOFaultManagement-API/NotificationEndpoint.robot b/SOL009/NFVMANOFaultManagement-API/NotificationEndpoint.robot index 3d7cfc802..ed61029e8 100644 --- a/SOL009/NFVMANOFaultManagement-API/NotificationEndpoint.robot +++ b/SOL009/NFVMANOFaultManagement-API/NotificationEndpoint.robot @@ -12,7 +12,7 @@ Suite Teardown Terminate All Processes kill=true NFV-MANO Fault Alarm Notification [Documentation] Test ID: 8.3.3.5.1 ... Test title: NFV-MANO Fault Alarm Notification - ... Test objective: The objective is to test the dispatch of NFV-MANO Fault Alarm Notification when a virtualised resource within an NFV-MANO instance fails, and perform a JSON schema and content validation of the delivered notification. The action that triggers the notification under test is an explicit test step, but it is not performed by the test system. + ... Test objective: The objective is to test the dispatch of NFV-MANO Fault Alarm Notification when a resource within an NFV-MANO instance fails, and perform a JSON schema and content validation of the delivered notification. The action that triggers the notification under test is an explicit test step, but it is not performed by the test system. ... Pre-conditions: A NFV-MANO instance is instantiated, and a subscription for fault alarm notifications is available. ... Reference: clause 7.5.7.3.1 - ETSI GS NFV-SOL 009 [5] V3.3.1 ... Config ID: Config_prod_NFV-MANO @@ -25,7 +25,7 @@ NFV-MANO Fault Alarm Notification NFV-MANO Fault Alarm Cleared Notification [Documentation] Test ID: 8.3.3.5.2 ... Test title: NFV-MANO Fault Alarm Cleared Notification - ... Test objective: The objective is to test the dispatch of NFV-MANO Fault Alarm Cleared Notification when a faulty virtualised resource within an NFV-MANO instance is cleared, and perform a JSON schema and content validation of the delivered notification. The action that triggers the notification under test is an explicit test step, but it is not performed by the test system. + ... Test objective: The objective is to test the dispatch of NFV-MANO Fault Alarm Cleared Notification when a faulty resource within an NFV-MANO instance is cleared, and perform a JSON schema and content validation of the delivered notification. The action that triggers the notification under test is an explicit test step, but it is not performed by the test system. ... Pre-conditions: A NFV-MANO instance is instantiated, a virtualised resource is in faulty state, and a subscription for fault alarm cleared notifications is available. ... Reference: clause 7.5.7.3.1 - ETSI GS NFV-SOL 009 [5] V3.3.1 ... Config ID: Config_prod_NFV-MANO diff --git a/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot b/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot index 2f4a25ac1..ab61f8d46 100644 --- a/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot +++ b/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot @@ -10,8 +10,8 @@ Library JSONSchemaLibrary schemas/ *** Test Cases *** Create a new Fault Management alarm subscription [Documentation] Test ID:8.3.3.3.1 - ... Test title: Create a new Fault Management alarm subscription - ... Test objective: The objective is to create a new Fault management alarm subscriptions and perform a JSON schema and content validation of the returned fault management alarms subscription data structure + ... Test title: Create a new fault management alarm subscription + ... Test objective: The objective is to create a new fault management alarm subscription and perform a JSON schema and content validation of the returned fault management alarms subscription data structure ... Pre-conditions: No subscription with the same filter and callbackUri exists ... Reference: clause 7.5.5.3.1 - ETSI GS NFV-SOL 009 [5] v3.3.1 ... Config ID: Config_prod_NFV-MANO @@ -21,7 +21,7 @@ Create a new Fault Management alarm subscription Check HTTP Response Status Code Is 201 Check Operation Occurrence Id Check HTTP Response Body Json Schema Is FmSubscription - + Check PostCondition Subscription is created Create a new alarm subscription - DUPLICATION [Documentation] Test ID: 8.3.3.3.2 @@ -120,7 +120,7 @@ Get information about multiple alarms - Bad Request Response too Big PUT subscriptions - Method not implemented [Documentation] Test ID: 8.3.3.3.9 ... Test title:PUT subscriptions - Method not implemented - ... Test objective: The objective is to test that PUT method is not allowed to for Fault management subscriptions on VNF + ... Test objective: The objective is to test that PUT method is not allowed to for fault management subscriptions on VNF ... Pre-conditions: none ... RReference: clause 7.5.5.3.3 - ETSI GS NFV-SOL 009 [5] v3.3.1 ... Config ID: Config_prod_NFV-MANO @@ -132,7 +132,7 @@ PUT subscriptions - Method not implemented PATCH subscriptions - Method not implemented [Documentation] Test ID: 8.3.3.3.10 ... Test title: PATCH subscriptions - Method not implemented - ... Test objective: The objective is to test that PATCH method is not allowed to for Fault management subscriptions on VNF + ... Test objective: The objective is to test that PATCH method is not allowed to for fault management subscriptions on VNF ... Pre-conditions: none ... Reference: clause 7.5.5.3.4 - ETSI GS NFV-SOL 009 [5] v3.3.1 ... Config ID: Config_prod_NFV-MANO @@ -144,7 +144,7 @@ PATCH subscriptions - Method not implemented DELETE subscriptions - Method not implemented [Documentation] Test ID: 8.3.3.3.11 ... Test title: DELETE subscriptions - Method not implemented - ... Test objective: The objective is to test that DELETE method is not allowed to for Fault management subscriptions on VNF + ... Test objective: The objective is to test that DELETE method is not allowed to for fault management subscriptions on VNF ... Pre-conditions: none ... Reference: clause 7.5.5.3.5 - ETSI GS NFV-SOL 009 [5] v3.3.1 ... Config ID: Config_prod_NFV-MANO -- GitLab From 4391ae5b0a4928945ff9d6fa36f9cd70437940f3 Mon Sep 17 00:00:00 2001 From: uihassan Date: Wed, 19 Aug 2020 15:56:34 +0500 Subject: [PATCH 11/22] Postcondition for creation of duplicate subscription added --- .../FaultManagement-APIKeyword.robot | 22 +++++++++++++++++++ .../Subscriptions.robot | 2 ++ 2 files changed, 24 insertions(+) diff --git a/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot b/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot index 75b547369..bcf560e44 100644 --- a/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot +++ b/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot @@ -201,6 +201,15 @@ POST Subscription Duplication permitted ${outputResponse}= Output response Set Global Variable @{response} ${outputResponse} +Check Postcondition FaultManagement Subscription Is Set + Log Check Postcondition subscription exist + Set Headers {"Accept": "${ACCEPT_JSON}"} + GET ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions/${response['body']['id']} + ${output}= Output response + Set Suite Variable ${response} ${output} + Check HTTP Response Status Code Is 200 + + POST Subscription Duplication not permitted Log Create subscription instance by POST to ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions Pass Execution If ${NFVMANO_DUPLICATION} == 1 NVFO is not permitting duplication. Skipping the test @@ -212,6 +221,19 @@ POST Subscription Duplication not permitted ${outputResponse}= Output response Set Global Variable @{response} ${outputResponse} +Check Postcondition Subscription Resource Returned in Location Header Is Available + Log Going to check postcondition + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"} + GET ${response['headers']['Location']} + Integer response status 200 + Log Received a 200 OK as expected + ${contentType}= Output response headers Content-Type + Should Contain ${contentType} application/json + ${result}= Output response body + Validate Json FMSubscription.schema.json ${result} + Log Validated FMSubscription schema + + GET Subscriptions Log Get the list of active subscriptions Set Headers {"Accept": "${ACCEPT}"} diff --git a/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot b/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot index ab61f8d46..3867997d9 100644 --- a/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot +++ b/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot @@ -36,6 +36,7 @@ Create a new alarm subscription - DUPLICATION Check HTTP Response Status Code Is 201 Check Operation Occurrence Id Check HTTP Response Body Json Schema Is FmSubscription + Check Postcondition FaultManagement Subscription Is Set Create a new alarm subscription - NO DUPLICATION [Documentation] Test ID: 8.3.3.3.3 @@ -50,6 +51,7 @@ Create a new alarm subscription - NO DUPLICATION Check HTTP Response Status Code Is 303 Check Operation Occurrence Id Check HTTP Response Body Json Schema Is FmSubscription + Check Postcondition Subscription Resource Returned in Location Header Is Available Retrieve a list of alarm subscriptions [Documentation] Test ID: 8.3.3.3.4 -- GitLab From 36ee759b3b8511d2ebc55ad2d44b4a3678f598de Mon Sep 17 00:00:00 2001 From: uihassan Date: Wed, 19 Aug 2020 15:59:37 +0500 Subject: [PATCH 12/22] Added postcondition for individualSubscription --- .../FaultManagement-APIKeyword.robot | 4 ++++ .../NFVMANOFaultManagement-API/IndividualSubscription.robot | 1 + 2 files changed, 5 insertions(+) diff --git a/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot b/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot index bcf560e44..b7b9174a6 100644 --- a/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot +++ b/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot @@ -290,6 +290,10 @@ POST Individual Subscription ${outputResponse}= Output response Set Global Variable @{response} ${outputResponse} +Check Postcondition subscription not created + GET Individual Subscription + Check HTTP Response Status Code Is 404 + GET Individual Subscription log Trying to get information about an individual subscription Set Headers {"Accept":"${ACCEPT}"} diff --git a/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot b/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot index 470d86a23..9d9b91a64 100644 --- a/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot +++ b/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot @@ -17,6 +17,7 @@ Post Individual Subscription - Method not implemented ... Post-Conditions: subscription is not created POST Individual Subscription Check HTTP Response Status Code Is 405 + Check Postcondition subscription not created Get Information about an individual subscription [Documentation] Test ID: 8.3.3.4.2 -- GitLab From 5f6f63d503d8a01f875e5dd13ac042345fad9172 Mon Sep 17 00:00:00 2001 From: uihassan Date: Fri, 21 Aug 2020 10:30:43 +0500 Subject: [PATCH 13/22] added test case for alarm attribute-based filtering --- .../NFVMANOFaultManagement-API/Alarms.robot | 72 +++++++++++++++++++ .../FaultManagement-APIKeyword.robot | 27 ++++++- .../environment/variables.txt | 3 + 3 files changed, 101 insertions(+), 1 deletion(-) diff --git a/SOL009/NFVMANOFaultManagement-API/Alarms.robot b/SOL009/NFVMANOFaultManagement-API/Alarms.robot index f9ee94c8a..bffdf4308 100644 --- a/SOL009/NFVMANOFaultManagement-API/Alarms.robot +++ b/SOL009/NFVMANOFaultManagement-API/Alarms.robot @@ -85,6 +85,78 @@ Get information about multiple alarms - Bad Request Response too Big GET Fault Management Alarms Check HTTP Response Status Code Is 400 Check HTTP Response Body Json Schema Is ProblemDetails + +GET information about alarms with attribute-based filter "id" + [Documentation] Test ID: 8.3.3.1.14 + ... Test title: GET information about alarms with attribute-based filter "id" + ... Test objective: The objective is to retrieve information about the alarm list with alarm filter "id" + ... Pre-conditions: + ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: + ... Post-Conditions: + GET Alarms Task with filter "id" + Check HTTP Response Status Code Is 200 + Check HTTP Response Body Json Schema Is Alarm + Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "id" + +GET information about multiple alarms with attribute-based filter "managedObjectId" + [Documentation] Test ID: 8.3.3.1.15 + ... Test title: GET information about multiple alarms with attribute-based filter "managedObjectId" + ... Test objective: The objective is to retrieve information about the alarm list with attribute filter "managedObjectId" + ... Pre-conditions: + ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: + ... Post-Conditions: + GET Alarms Task with filter "managedObjectId" + Check HTTP Response Status Code Is 200 + Check HTTP Response Body Json Schema Is Alarms + Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "managedObjectId" + +GET information about multiple alarms with attribute-based filter "eventType" + [Documentation] Test ID: 8.3.3.1.17 + ... Test title: GET information about multiple alarms with attribute-based filter "eventType" + ... Test objective: The objective is to retrieve information about the alarm list with attribute filter "eventType" + ... Pre-conditions: + ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: + ... Post-Conditions: + GET Alarms Task with filter "eventType" + Check HTTP Response Status Code Is 200 + Check HTTP Response Body Json Schema Is Alarms + Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "eventType" + +GET information about multiple alarms with attribute-based filter "perceivedSeverity" + [Documentation] Test ID: 8.3.3.1.18 + ... Test title: GET information about multiple alarms with attribute-based filter "perceivedSeverity" + ... Test objective: The objective is to retrieve information about the alarm list with attribute filter "perceivedSeverity" + ... Pre-conditions: + ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: + ... Post-Conditions: + GET Alarms Task with filter "perceivedSeverity" + Check HTTP Response Status Code Is 200 + Check HTTP Response Body Json Schema Is Alarms + Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "perceivedSeverity" + +GET information about multiple alarms with attribute-based filter "probableCause" + [Documentation] Test ID: 8.3.3.1.19 + ... Test title: GET information about multiple alarms with attribute-based filter "probableCause" + ... Test objective: The objective is to retrieve information about the alarm list with attribute filter "probableCause" + ... Pre-conditions: + ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: + ... Post-Conditions: + GET Alarms Task with filter "probableCause" + Check HTTP Response Status Code Is 200 + Check HTTP Response Body Json Schema Is Alarms + Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "probableCause" + + PUT Alarms - Method not implemented [Documentation] Test ID: 8.3.3.1.7 diff --git a/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot b/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot index b7b9174a6..7560790ba 100644 --- a/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot +++ b/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot @@ -330,4 +330,29 @@ Check Individual Subscription deleted Set Headers {"Accept":"${ACCEPT}"} Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} Get ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions/${subscriptionId} - Integer response status 404 \ No newline at end of file + Integer response status 404 + +GET Alarms Task with filter "id" + Log Query NFV-MANO The GET method queries information about multiple alarms with filters "id". + Set Headers {"Accept":"${ACCEPT}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} + Log Execute Query and validate response + Get ${apiRoot}/${apiName}/${apiMajorVersion}/alarms?id=${alarmId} + ${outputResponse}= Output response + Set Global Variable ${response} ${outputResponse} + +Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "id" + Should Be Equal As Strings ${response['body']['id']} ${alarmId} + +GET Alarms Task with filter "managedObjectId" + Log Query VNF The GET method queries information about multiple alarms with filters "vnfcInstanceIds". + Set Headers {"Accept":"${ACCEPT}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} + Log Execute Query and validate response + Get ${apiRoot}/${apiName}/${apiMajorVersion}/alarms?vnfcInstanceIds=${managedObjectId} + ${outputResponse}= Output response + Set Global Variable ${response} ${outputResponse} + +Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "managedObjectId" + Should Be Equal As Strings ${response['body']['managedObjectId']} ${managedObjectId} + diff --git a/SOL009/NFVMANOFaultManagement-API/environment/variables.txt b/SOL009/NFVMANOFaultManagement-API/environment/variables.txt index eee387083..39094b638 100644 --- a/SOL009/NFVMANOFaultManagement-API/environment/variables.txt +++ b/SOL009/NFVMANOFaultManagement-API/environment/variables.txt @@ -18,6 +18,9 @@ ${CONTENT_TYPE_PATCH} application/merge-patch+json ${alarm_filter} managedObjectId ${managedObjectId} 007c111c-38a1-42c0-a666-7475ecb1567c +${eventType} COMMUNICATIONS_ALARM +${probableCause} "" +${perceivedSeverity} CRITICAL ${invalid_alarm_filter} badFilter ${alarmId} 6fc3539c-e602-4afa-8e13-962fb5a7d81d -- GitLab From 69eeae29e86f118558950cfb06c04e419faa6adf Mon Sep 17 00:00:00 2001 From: uihassan Date: Fri, 21 Aug 2020 10:31:55 +0500 Subject: [PATCH 14/22] change TD ids --- SOL009/NFVMANOFaultManagement-API/Alarms.robot | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/SOL009/NFVMANOFaultManagement-API/Alarms.robot b/SOL009/NFVMANOFaultManagement-API/Alarms.robot index bffdf4308..79bbeff5d 100644 --- a/SOL009/NFVMANOFaultManagement-API/Alarms.robot +++ b/SOL009/NFVMANOFaultManagement-API/Alarms.robot @@ -87,7 +87,7 @@ Get information about multiple alarms - Bad Request Response too Big Check HTTP Response Body Json Schema Is ProblemDetails GET information about alarms with attribute-based filter "id" - [Documentation] Test ID: 8.3.3.1.14 + [Documentation] Test ID: 8.3.3.1.7 ... Test title: GET information about alarms with attribute-based filter "id" ... Test objective: The objective is to retrieve information about the alarm list with alarm filter "id" ... Pre-conditions: @@ -101,7 +101,7 @@ GET information about alarms with attribute-based filter "id" Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "id" GET information about multiple alarms with attribute-based filter "managedObjectId" - [Documentation] Test ID: 8.3.3.1.15 + [Documentation] Test ID: 8.3.3.1.8 ... Test title: GET information about multiple alarms with attribute-based filter "managedObjectId" ... Test objective: The objective is to retrieve information about the alarm list with attribute filter "managedObjectId" ... Pre-conditions: @@ -115,7 +115,7 @@ GET information about multiple alarms with attribute-based filter "managedObject Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "managedObjectId" GET information about multiple alarms with attribute-based filter "eventType" - [Documentation] Test ID: 8.3.3.1.17 + [Documentation] Test ID: 8.3.3.1.9 ... Test title: GET information about multiple alarms with attribute-based filter "eventType" ... Test objective: The objective is to retrieve information about the alarm list with attribute filter "eventType" ... Pre-conditions: @@ -129,7 +129,7 @@ GET information about multiple alarms with attribute-based filter "eventType" Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "eventType" GET information about multiple alarms with attribute-based filter "perceivedSeverity" - [Documentation] Test ID: 8.3.3.1.18 + [Documentation] Test ID: 8.3.3.1.10 ... Test title: GET information about multiple alarms with attribute-based filter "perceivedSeverity" ... Test objective: The objective is to retrieve information about the alarm list with attribute filter "perceivedSeverity" ... Pre-conditions: @@ -143,7 +143,7 @@ GET information about multiple alarms with attribute-based filter "perceivedSeve Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "perceivedSeverity" GET information about multiple alarms with attribute-based filter "probableCause" - [Documentation] Test ID: 8.3.3.1.19 + [Documentation] Test ID: 8.3.3.1.11 ... Test title: GET information about multiple alarms with attribute-based filter "probableCause" ... Test objective: The objective is to retrieve information about the alarm list with attribute filter "probableCause" ... Pre-conditions: @@ -156,10 +156,8 @@ GET information about multiple alarms with attribute-based filter "probableCause Check HTTP Response Body Json Schema Is Alarms Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "probableCause" - - PUT Alarms - Method not implemented - [Documentation] Test ID: 8.3.3.1.7 + [Documentation] Test ID: 8.3.3.1.12 ... Test title: PUT Alarms - Method not implemented ... Test objective: The objective is to test that PUT method is not allowed to modify fault management alarms on NFV-MANO. ... Pre-conditions: none @@ -171,7 +169,7 @@ PUT Alarms - Method not implemented Check HTTP Response Status Code Is 405 PATCH Alarms - Method not implemented - [Documentation] Test ID: 8.3.3.1.8 + [Documentation] Test ID: 8.3.3.1.13 ... Test title: PATCH Alarms - Method not implemented ... Test objective: The objective is to test that PATCH method is not allowed to modify fault management alarms on NFV-MANO. ... Pre-conditions: none @@ -183,7 +181,7 @@ PATCH Alarms - Method not implemented Check HTTP Response Status Code Is 405 DELETE Alarms - Method not implemented - [Documentation] Test ID: 8.3.3.1.9 + [Documentation] Test ID: 8.3.3.1.14 ... Test title: POST Alarms - Method not implemented ... Test objective: The objective is to test that DELETE method is not allowed for fault management alarms on NFV-MANO ... Pre-conditions: none -- GitLab From 438a2ccdecf7582b5511323fc42f33175e34364c Mon Sep 17 00:00:00 2001 From: uihassan Date: Fri, 21 Aug 2020 10:43:37 +0500 Subject: [PATCH 15/22] added test case for subscription attribute-based filtering --- .../FaultManagement-APIKeyword.robot | 108 +++++++++++++++++- .../Subscriptions.robot | 78 ++++++++++++- .../environment/variables.txt | 2 + 3 files changed, 183 insertions(+), 5 deletions(-) diff --git a/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot b/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot index 7560790ba..97fdd3b16 100644 --- a/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot +++ b/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot @@ -345,14 +345,118 @@ Check PostCondition HTTP Response Body alarms Matches the requested attribute-ba Should Be Equal As Strings ${response['body']['id']} ${alarmId} GET Alarms Task with filter "managedObjectId" - Log Query VNF The GET method queries information about multiple alarms with filters "vnfcInstanceIds". + Log Query NFV-MANO The GET method queries information about multiple alarms with filters "NFV-MANOcInstanceIds". Set Headers {"Accept":"${ACCEPT}"} Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} Log Execute Query and validate response - Get ${apiRoot}/${apiName}/${apiMajorVersion}/alarms?vnfcInstanceIds=${managedObjectId} + Get ${apiRoot}/${apiName}/${apiMajorVersion}/alarms?NFV-MANOcInstanceIds=${managedObjectId} ${outputResponse}= Output response Set Global Variable ${response} ${outputResponse} Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "managedObjectId" Should Be Equal As Strings ${response['body']['managedObjectId']} ${managedObjectId} +GET Alarms Task with filter "eventType" + Log Query NFV-MANO The GET method queries information about multiple alarms with filters "eventType". + Set Headers {"Accept":"${ACCEPT}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} + Log Execute Query and validate response + Get ${apiRoot}/${apiName}/${apiMajorVersion}/alarms?eventType=${eventType} + ${outputResponse}= Output response + Set Global Variable ${response} ${outputResponse} + +Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "eventType" + :FOR ${item} IN @{response['body']} + Should Be Equal As Strings ${item['eventType']} ${eventType} + END + +GET Alarms Task with filter "perceivedSeverity" + Log Query NFV-MANO The GET method queries information about multiple alarms with filters "perceivedSeverity". + Set Headers {"Accept":"${ACCEPT}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} + Log Execute Query and validate response + Get ${apiRoot}/${apiName}/${apiMajorVersion}/alarms?perceivedSeverity=${perceivedSeverity} + ${outputResponse}= Output response + Set Global Variable ${response} ${outputResponse} + +Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "perceivedSeverity" + :FOR ${item} IN @{response['body']} + Should Be Equal As Strings ${item['perceivedSeverity']} ${perceivedSeverity} + END + +GET Alarms Task with filter "probableCause" + Log Query NFV-MANO The GET method queries information about multiple alarms with filters "probableCause". + Set Headers {"Accept":"${ACCEPT}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} + Log Execute Query and validate response + Get ${apiRoot}/${apiName}/${apiMajorVersion}/alarms?probableCause=${probableCause} + ${outputResponse}= Output response + Set Global Variable ${response} ${outputResponse} + +Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "probableCause" + :FOR ${item} IN @{response['body']} + Should Be Equal As Strings ${item['probableCause']} ${probableCause} + END + +Get subscriptions with filter "id" + Log Get the list of active subscriptions using a filter "id" + Set Headers {"Accept": "${ACCEPT}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"} + GET ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions?id=${subscription_id} + ${outputResponse}= Output response + Set Global Variable ${response} ${outputResponse} + +Check PostCondition HTTP Response Body Subscription Matches the requested attribute-based filter "id" + Should Be Equal As Strings ${response['body']['id']} ${subscription_id} + +Get subscriptions with filter "filter_notificationTypes" + Log Get the list of active subscriptions using a filter "filter.notificationTypes" + Set Headers {"Accept": "${ACCEPT}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"} + GET ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions?filter.notificationTypes=${notification_type} + ${outputResponse}= Output response + Set Global Variable ${response} ${outputResponse} + +Check PostCondition HTTP Response Body Subscriptions Matches the requested attribute-based filter "filter_notificationTypes" + :FOR ${item} IN @{response['body']} + Should Be Equal As Strings ${item['filter']['notificationTypes']} ${notification_type} + END + +Get subscriptions with filter "filter_perceivedSeverities" + Log Get the list of active subscriptions using a filter "filter.perceivedSeverities" + Set Headers {"Accept": "${ACCEPT}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"} + GET ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions?filter.perceivedSeverities=${perceivedSeverity} + ${outputResponse}= Output response + Set Global Variable ${response} ${outputResponse} + +Check PostCondition HTTP Response Body Subscriptions Matches the requested attribute-based filter "filter_perceivedSeverities" + :FOR ${item} IN @{response['body']} + Should Be Equal As Strings ${item['filter']['perceivedSeverities']} ${perceivedSeverity} + END + +Get subscriptions with filter "filter_eventTypes" + Log Get the list of active subscriptions using a filter "filter.eventTypes" + Set Headers {"Accept": "${ACCEPT}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"} + GET ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions?filter.eventTypes=${eventType} + ${outputResponse}= Output response + Set Global Variable ${response} ${outputResponse} + +Check PostCondition HTTP Response Body Subscriptions Matches the requested attribute-based filter "filter_eventTypes" + :FOR ${item} IN @{response['body']} + Should Be Equal As Strings ${item['filter']['eventTypes']} ${eventType} + END + +Get subscriptions with filter "filter_probableCauses" + Log Get the list of active subscriptions using a filter "filter.probableCauses" + Set Headers {"Accept": "${ACCEPT}"} + Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization": "${AUTHORIZATION}"} + GET ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions?filter.probableCauses=${probableCause} + ${outputResponse}= Output response + Set Global Variable ${response} ${outputResponse} + +Check PostCondition HTTP Response Body Subscriptions Matches the requested attribute-based filter "filter_probableCauses" + :FOR ${item} IN @{response['body']} + Should Be Equal As Strings ${item['filter']['probableCauses']} ${probableCause} + END diff --git a/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot b/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot index 3867997d9..9983932ed 100644 --- a/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot +++ b/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot @@ -119,8 +119,80 @@ Get information about multiple alarms - Bad Request Response too Big Check HTTP Response Status Code Is 400 Check HTTP Response Body Json Schema Is ProblemDetails -PUT subscriptions - Method not implemented +GET Subscription with attribute-based filter "id" [Documentation] Test ID: 8.3.3.3.9 + ... Test title: GET Subscription with attribute-based filter "id" + ... Test objective: The objective is to retrieve the list of active subscriptions with filter "id" + ... Pre-conditions: + ... Reference: Clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: + ... Post-Conditions: + Get subscriptions with filter "id" + Check HTTP Response Status Code Is 200 + Check HTTP Response Body Json Schema Is FmSubscription + Check PostCondition HTTP Response Body Subscription Matches the requested attribute-based filter "id" + + +Get subscriptions with filter "filter.notificationTypes" + [Documentation] Test ID: 8.3.3.3.10 + ... Test title: GET Subscription with attribute-based filter "filter.notificationTypes" + ... Test objective: The objective is to retrieve the list of active subscriptions with filter "filter.notificationTypes" + ... Pre-conditions: + ... Reference: Clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: + ... Post-Conditions: + Get subscriptions with filter "filter_notificationTypes" + Check HTTP Response Status Code Is 200 + Check HTTP Response Body Json Schema Is FmSubscriptions + Check PostCondition HTTP Response Body Subscriptions Matches the requested attribute-based filter "filter_notificationTypes" + +Get subscriptions with filter "filter.perceivedSeverities" + [Documentation] Test ID: 8.3.3.3.11 + ... Test title: GET Subscription with attribute-based filter "filter.perceivedSeverities" + ... Test objective: The objective is to retrieve the list of active subscriptions with filter "filter.perceivedSeverities" + ... Pre-conditions: + ... Reference: Clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: + ... Post-Conditions: + Get subscriptions with filter "filter_perceivedSeverities" + Check HTTP Response Status Code Is 200 + Check HTTP Response Body Json Schema Is FmSubscriptions + Check PostCondition HTTP Response Body Subscriptions Matches the requested attribute-based filter "filter_perceivedSeverities" + +Get subscriptions with filter "filter.eventTypes" + [Documentation] Test ID: 8.3.3.3.12 + ... Test title: GET Subscription with attribute-based filter "filter.eventTypes" + ... Test objective: The objective is to retrieve the list of active subscriptions with filter "filter.eventTypes" + ... Pre-conditions: + ... Reference: Clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: + ... Post-Conditions: + Get subscriptions with filter "filter_eventTypes" + Check HTTP Response Status Code Is 200 + Check HTTP Response Body Json Schema Is FmSubscriptions + Check PostCondition HTTP Response Body Subscriptions Matches the requested attribute-based filter "filter_eventTypes" + +Get subscriptions with filter "filter.probableCauses" + [Documentation] Test ID: 8.3.3.3.13 + ... Test title: GET Subscription with attribute-based filter "filter.probableCauses" + ... Test objective: The objective is to retrieve the list of active subscriptions with filter "filter.probableCauses" + ... Pre-conditions: + ... Reference: Clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: + ... Post-Conditions: + Get subscriptions with filter "filter_probableCauses" + Check HTTP Response Status Code Is 200 + Check HTTP Response Body Json Schema Is FmSubscriptions + Check PostCondition HTTP Response Body Subscriptions Matches the requested attribute-based filter "filter_probableCauses" + + +PUT subscriptions - Method not implemented + [Documentation] Test ID: 8.3.3.3.14 ... Test title:PUT subscriptions - Method not implemented ... Test objective: The objective is to test that PUT method is not allowed to for fault management subscriptions on VNF ... Pre-conditions: none @@ -132,7 +204,7 @@ PUT subscriptions - Method not implemented Check HTTP Response Status Code Is 405 PATCH subscriptions - Method not implemented - [Documentation] Test ID: 8.3.3.3.10 + [Documentation] Test ID: 8.3.3.3.15 ... Test title: PATCH subscriptions - Method not implemented ... Test objective: The objective is to test that PATCH method is not allowed to for fault management subscriptions on VNF ... Pre-conditions: none @@ -144,7 +216,7 @@ PATCH subscriptions - Method not implemented Check HTTP Response Status Code Is 405 DELETE subscriptions - Method not implemented - [Documentation] Test ID: 8.3.3.3.11 + [Documentation] Test ID: 8.3.3.3.16 ... Test title: DELETE subscriptions - Method not implemented ... Test objective: The objective is to test that DELETE method is not allowed to for fault management subscriptions on VNF ... Pre-conditions: none diff --git a/SOL009/NFVMANOFaultManagement-API/environment/variables.txt b/SOL009/NFVMANOFaultManagement-API/environment/variables.txt index 39094b638..c58650bcc 100644 --- a/SOL009/NFVMANOFaultManagement-API/environment/variables.txt +++ b/SOL009/NFVMANOFaultManagement-API/environment/variables.txt @@ -33,6 +33,8 @@ ${sub_filter} filter ${sub_filter_invalid} filter_invalid ${subscriptionId} 6fc3539c-e602-4afa-8e13-962fb5a7d81f +${faultyResourceType} +${notification_type} AlarmNotification ${callback_uri} http://localhost ${callback_port} 9091 -- GitLab From ba0cc1618d03ef0c9520d591aeda9a5a6bbc11c9 Mon Sep 17 00:00:00 2001 From: Giacomo Bernini Date: Thu, 10 Sep 2020 18:21:27 +0200 Subject: [PATCH 16/22] added authentication tests + fixed some keywords --- .../NFVMANOFaultManagement-API/Alarms.robot | 92 +++++++++++++------ .../FaultManagement-APIKeyword.robot | 43 +++++++-- .../Subscriptions.robot | 22 ++--- .../environment/variables.txt | 4 +- 4 files changed, 113 insertions(+), 48 deletions(-) diff --git a/SOL009/NFVMANOFaultManagement-API/Alarms.robot b/SOL009/NFVMANOFaultManagement-API/Alarms.robot index 79bbeff5d..1eedfd8b9 100644 --- a/SOL009/NFVMANOFaultManagement-API/Alarms.robot +++ b/SOL009/NFVMANOFaultManagement-API/Alarms.robot @@ -23,7 +23,7 @@ POST Alarms - Method not implemented Get information about multiple alarms [Documentation] Test ID: 8.3.3.1.2 ... Test title: Get information about multiple alarms - ... Test objective: The objective is to retrieve information about the alarm list and perform a JSON schema and content validation of the returned alarms data structure + ... Test objective: The objective is to retrieve information about the alarm list and perform a JSON schema of the returned alarms data structure ... Pre-conditions: none ... Reference: clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] V3.3.1 ... Config ID: Config_prod_NFV-MANO @@ -36,7 +36,7 @@ Get information about multiple alarms Get information about multiple alarms with filter [Documentation] Test ID: 8.3.3.1.3 ... Test title: Get information about multiple alarms with filter - ... Test objective: The objective is to retrieve information about the alarm list and perform a JSON schema and content validation of the returned alarms data structure, and verify that the retrieved information matches the issued attribute-based filters + ... Test objective: The objective is to retrieve information about the alarm list and perform a JSON schema validation of the returned alarms data structure, and verify that the retrieved information matches the issued attribute-based filters ... Pre-conditions: none ... Reference: clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] V3.3.1 ... Config ID: Config_prod_NFV-MANO @@ -46,10 +46,10 @@ Get information about multiple alarms with filter Check HTTP Response Status Code Is 200 Check HTTP Response Body Json Schema Is Alarms -Get information about multiple alarms Bad Request Invalid attribute-based filtering parameters +Get information about multiple alarms with invalid attribute-based filtering parameters [Documentation] Test ID: 8.3.3.1.4 - ... Test title: Get information about multiple alarms Bad Request Invalid attribute-based filtering parameters - ... Test objective: The objective is to try to retrieve information about the alarm list with invalid filters and perform a JSON schema and content validation of the returned problem details data structure + ... Test title: Get information about multiple alarms with invalid attribute-based filtering parameters + ... Test objective: The objective is to try to retrieve information about the alarm list with invalid filters and perform a JSON schema validation of the returned problem details data structure ... Pre-conditions: none ... Reference: clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] V3.3.1 ... Config ID: Config_prod_NFV-MANO @@ -71,12 +71,12 @@ Get information about multiple alarms as a Paged Response ... Post-Conditions: none GET Fault Management Alarms Check HTTP Response Status Code Is 200 - Check LINK in Header + Check HTTP Response Header Contains Link Get information about multiple alarms - Bad Request Response too Big [Documentation] Test ID: 8.3.3.1.6 ... Test title: Get information about multiple alarms - Bad Request Response too Big - ... Test objective: The objective is to try to retrieve information about the alarm list because response is too big and perform a JSON schema and content validation of the returned problem details data structure + ... Test objective: The objective is to try to retrieve information about the alarm list because response is too big and perform a JSON schema validation of the returned problem details data structure ... Pre-conditions: none ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 ... Config ID: Config_prod_NFV-MANO @@ -90,12 +90,12 @@ GET information about alarms with attribute-based filter "id" [Documentation] Test ID: 8.3.3.1.7 ... Test title: GET information about alarms with attribute-based filter "id" ... Test objective: The objective is to retrieve information about the alarm list with alarm filter "id" - ... Pre-conditions: + ... Pre-conditions: none ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 ... Config ID: Config_prod_NFV-MANO - ... Applicability: - ... Post-Conditions: - GET Alarms Task with filter "id" + ... Applicability: none + ... Post-Conditions: none + GET Fault Management Alarms with filter "id" Check HTTP Response Status Code Is 200 Check HTTP Response Body Json Schema Is Alarm Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "id" @@ -107,9 +107,9 @@ GET information about multiple alarms with attribute-based filter "managedObject ... Pre-conditions: ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 ... Config ID: Config_prod_NFV-MANO - ... Applicability: - ... Post-Conditions: - GET Alarms Task with filter "managedObjectId" + ... Applicability: none + ... Post-Conditions: none + GET Fault Management Alarms with filter "managedObjectId" Check HTTP Response Status Code Is 200 Check HTTP Response Body Json Schema Is Alarms Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "managedObjectId" @@ -121,9 +121,9 @@ GET information about multiple alarms with attribute-based filter "eventType" ... Pre-conditions: ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 ... Config ID: Config_prod_NFV-MANO - ... Applicability: - ... Post-Conditions: - GET Alarms Task with filter "eventType" + ... Applicability: none + ... Post-Conditions: none + GET Fault Management Alarms with filter "eventType" Check HTTP Response Status Code Is 200 Check HTTP Response Body Json Schema Is Alarms Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "eventType" @@ -132,12 +132,12 @@ GET information about multiple alarms with attribute-based filter "perceivedSeve [Documentation] Test ID: 8.3.3.1.10 ... Test title: GET information about multiple alarms with attribute-based filter "perceivedSeverity" ... Test objective: The objective is to retrieve information about the alarm list with attribute filter "perceivedSeverity" - ... Pre-conditions: + ... Pre-conditions: none ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 ... Config ID: Config_prod_NFV-MANO - ... Applicability: - ... Post-Conditions: - GET Alarms Task with filter "perceivedSeverity" + ... Applicability: none + ... Post-Conditions: none + GET Fault Management Alarms with filter "perceivedSeverity" Check HTTP Response Status Code Is 200 Check HTTP Response Body Json Schema Is Alarms Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "perceivedSeverity" @@ -146,18 +146,54 @@ GET information about multiple alarms with attribute-based filter "probableCause [Documentation] Test ID: 8.3.3.1.11 ... Test title: GET information about multiple alarms with attribute-based filter "probableCause" ... Test objective: The objective is to retrieve information about the alarm list with attribute filter "probableCause" - ... Pre-conditions: + ... Pre-conditions: none ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 ... Config ID: Config_prod_NFV-MANO - ... Applicability: - ... Post-Conditions: - GET Alarms Task with filter "probableCause" + ... Applicability: none + ... Post-Conditions: none + GET Fault Management Alarms with filter "probableCause" Check HTTP Response Status Code Is 200 Check HTTP Response Body Json Schema Is Alarms Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "probableCause" -PUT Alarms - Method not implemented +Get information about multiple alarms with malformed authorization token [Documentation] Test ID: 8.3.3.1.12 + ... Test title: Get information about multiple alarms with malformed authorization token + ... Test objective: The objective is to test that the retrieval of information about the alarm list fails when using malformed authorization token + ... Pre-conditions: none + ... Reference: clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [3] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: The NFV-MANO entity requires the usage of access tokens for authorizing the API requests. + ... Post-Conditions: none + GET Fault Management Alarms with malformed authorization token + Check HTTP Response Status Code Is 400 + +Get information about multiple alarms without authorization token + [Documentation] Test ID: 8.3.3.1.13 + ... Test title: Get information about multiple alarms without authorization token + ... Test objective: The objective is to test that the retrieval of information about the alarm list fails when omitting the authorization token + ... Pre-conditions: none + ... Reference: clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [3] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: The NFV-MANO entity requires the usage of access tokens for authorizing the API requests. + ... Post-Conditions: none + GET Fault Management Alarms without authorization token + Check HTTP Response Status Code Is 401 + +GET information about multiple alarms with expired or revoked authorization token + [Documentation] Test ID: 8.3.3.1.14 + ... Test title: GET information about multiple alarms with expired or revoked authorization token + ... Test objective: The objective is to test that the retrieval of information about the alarm list fails when using expired or revoked authorization token + ... Pre-conditions: One or more Network Service Descriptors are onboarded in the NFVO + ... Reference: clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [3] v3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: The NFV-MANO entity requires the usage of access tokens for authorizing the API requests. + ... Post-Conditions: none + GET Fault Management Alarms with expired or revoked authorization token + Check HTTP Response Status Code Is 401 + +PUT Alarms - Method not implemented + [Documentation] Test ID: 8.3.3.1.15 ... Test title: PUT Alarms - Method not implemented ... Test objective: The objective is to test that PUT method is not allowed to modify fault management alarms on NFV-MANO. ... Pre-conditions: none @@ -169,7 +205,7 @@ PUT Alarms - Method not implemented Check HTTP Response Status Code Is 405 PATCH Alarms - Method not implemented - [Documentation] Test ID: 8.3.3.1.13 + [Documentation] Test ID: 8.3.3.1.16 ... Test title: PATCH Alarms - Method not implemented ... Test objective: The objective is to test that PATCH method is not allowed to modify fault management alarms on NFV-MANO. ... Pre-conditions: none @@ -181,7 +217,7 @@ PATCH Alarms - Method not implemented Check HTTP Response Status Code Is 405 DELETE Alarms - Method not implemented - [Documentation] Test ID: 8.3.3.1.14 + [Documentation] Test ID: 8.3.3.1.17 ... Test title: POST Alarms - Method not implemented ... Test objective: The objective is to test that DELETE method is not allowed for fault management alarms on NFV-MANO ... Pre-conditions: none diff --git a/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot b/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot index 97fdd3b16..cc846559f 100644 --- a/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot +++ b/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot @@ -60,7 +60,7 @@ GET Fault Management Alarms With Invalid Filters ${outputResponse}= Output response Set Global Variable @{response} ${outputResponse} -Check LINK in Header +Check HTTP Response Header Contains Link ${linkURL}= Get Value From Json ${response['headers']} $..Link Should Not Be Empty ${linkURL} @@ -178,7 +178,7 @@ POST Subscription ${outputResponse}= Output response Set Global Variable @{response} ${outputResponse} -Check Operation Occurrence Id +Check HTTP Response Header Contains Location ${opOccId}= Get Value From Json ${response['headers']} $..Location Should Not Be Empty ${opOccId} @@ -332,7 +332,7 @@ Check Individual Subscription deleted Get ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions/${subscriptionId} Integer response status 404 -GET Alarms Task with filter "id" +GET Fault Management Alarms with filter "id" Log Query NFV-MANO The GET method queries information about multiple alarms with filters "id". Set Headers {"Accept":"${ACCEPT}"} Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} @@ -344,7 +344,7 @@ GET Alarms Task with filter "id" Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "id" Should Be Equal As Strings ${response['body']['id']} ${alarmId} -GET Alarms Task with filter "managedObjectId" +GET Fault Management Alarms with filter "managedObjectId" Log Query NFV-MANO The GET method queries information about multiple alarms with filters "NFV-MANOcInstanceIds". Set Headers {"Accept":"${ACCEPT}"} Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} @@ -356,7 +356,7 @@ GET Alarms Task with filter "managedObjectId" Check PostCondition HTTP Response Body alarms Matches the requested attribute-based filter "managedObjectId" Should Be Equal As Strings ${response['body']['managedObjectId']} ${managedObjectId} -GET Alarms Task with filter "eventType" +GET Fault Management Alarms with filter "eventType" Log Query NFV-MANO The GET method queries information about multiple alarms with filters "eventType". Set Headers {"Accept":"${ACCEPT}"} Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} @@ -370,7 +370,7 @@ Check PostCondition HTTP Response Body alarms Matches the requested attribute-ba Should Be Equal As Strings ${item['eventType']} ${eventType} END -GET Alarms Task with filter "perceivedSeverity" +GET Fault Management Alarms with filter "perceivedSeverity" Log Query NFV-MANO The GET method queries information about multiple alarms with filters "perceivedSeverity". Set Headers {"Accept":"${ACCEPT}"} Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} @@ -384,7 +384,7 @@ Check PostCondition HTTP Response Body alarms Matches the requested attribute-ba Should Be Equal As Strings ${item['perceivedSeverity']} ${perceivedSeverity} END -GET Alarms Task with filter "probableCause" +GET Fault Management Alarms with filter "probableCause" Log Query NFV-MANO The GET method queries information about multiple alarms with filters "probableCause". Set Headers {"Accept":"${ACCEPT}"} Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} @@ -460,3 +460,32 @@ Check PostCondition HTTP Response Body Subscriptions Matches the requested attri :FOR ${item} IN @{response['body']} Should Be Equal As Strings ${item['filter']['probableCauses']} ${probableCause} END + +GET Fault Management Alarms with malformed authorization token + Pass Execution If ${AUTH_USAGE} == 0 Skipping test as NFVO is not supporting authentication + Log The GET method queries using invalid token + Set Headers {"Accept": "${ACCEPT_JSON}"} + Set Headers {"Authorization": "${BAD_AUTHORIZATION}"} + Log Execute Query and validate response + Get ${apiRoot}/${apiName}/${apiMajorVersion}/alarms + ${output}= Output response + Set Suite Variable ${response} ${output} + +GET Fault Management Alarms without authorization token + Pass Execution If ${AUTH_USAGE} == 0 Skipping test as it is not supporting authentication + Log The GET method queries omitting token + Set Headers {"Accept": "${ACCEPT_JSON}"} + Log Execute Query and validate response + Get ${apiRoot}/${apiName}/${apiMajorVersion}/alarms + ${output}= Output response + Set Suite Variable ${response} ${output} + +GET Fault Management Alarms with expired or revoked authorization token + Pass Execution If ${AUTH_USAGE} == 0 Skipping test as it is not supporting authentication + Log The GET method queries using invalid token + Set Headers {"Accept": "${ACCEPT_JSON}"} + Set Headers {"Authorization": "${NEG_AUTHORIZATION}"} + Log Execute Query and validate response + Get ${apiRoot}/${apiName}/${apiMajorVersion}/alarms + ${output}= Output response + Set Suite Variable ${response} ${output} \ No newline at end of file diff --git a/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot b/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot index 9983932ed..caec27420 100644 --- a/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot +++ b/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot @@ -11,7 +11,7 @@ Library JSONSchemaLibrary schemas/ Create a new Fault Management alarm subscription [Documentation] Test ID:8.3.3.3.1 ... Test title: Create a new fault management alarm subscription - ... Test objective: The objective is to create a new fault management alarm subscription and perform a JSON schema and content validation of the returned fault management alarms subscription data structure + ... Test objective: The objective is to create a new fault management alarm subscription and perform a JSON schema validation of the returned fault management alarms subscription data structure ... Pre-conditions: No subscription with the same filter and callbackUri exists ... Reference: clause 7.5.5.3.1 - ETSI GS NFV-SOL 009 [5] v3.3.1 ... Config ID: Config_prod_NFV-MANO @@ -19,14 +19,14 @@ Create a new Fault Management alarm subscription ... Post-Conditions: subscription is created POST Subscription Check HTTP Response Status Code Is 201 - Check Operation Occurrence Id Check HTTP Response Body Json Schema Is FmSubscription + Check HTTP Response Header Contains Location Check PostCondition Subscription is created Create a new alarm subscription - DUPLICATION [Documentation] Test ID: 8.3.3.3.2 ... Test title: Create a new alarm subscription - DUPLICATION - ... Test objective: The objective is to create a new subscription with the NFV-MANO allowing duplication and perform a JSON schema and content validation of the returned fault management alarms subscription data structure. + ... Test objective: The objective is to create a new subscription with the NFV-MANO allowing duplication and perform a JSON schema validation of the returned fault management alarms subscription data structure. ... Pre-conditions: subscription with the same filter and callbackUri exists ... Reference: clause 7.5.5.3.1 - ETSI GS NFV-SOL 009 [5] v3.3.1 ... Config ID: Config_prod_NFV-MANO @@ -34,14 +34,14 @@ Create a new alarm subscription - DUPLICATION ... Post-Conditions: duplicated subscription is created POST Subscription Duplication permitted Check HTTP Response Status Code Is 201 - Check Operation Occurrence Id Check HTTP Response Body Json Schema Is FmSubscription + Check HTTP Response Header Contains Location Check Postcondition FaultManagement Subscription Is Set Create a new alarm subscription - NO DUPLICATION [Documentation] Test ID: 8.3.3.3.3 ... Test title: Create a new alarm subscription - NO DUPLICATION - ... Test objective: The objective is to create a new subscription with the NFV-MANO not allowing duplication and perform a JSON schema and content validation of the returned fault management alarms subscription data structure. + ... Test objective: The objective is to create a new subscription with the NFV-MANO not allowing duplication and perform a JSON schema validation of the returned fault management alarms subscription data structure. ... Pre-conditions: subscription with the same filter and callbackUri exists ... Reference: clause 7.5.5.3.1 - ETSI GS NFV-SOL 009 [5] v3.3.1 ... Config ID: Config_prod_NFV-MANO @@ -49,14 +49,14 @@ Create a new alarm subscription - NO DUPLICATION ... Post-Conditions: duplicated subscription is not created POST Subscription Duplication not permitted Check HTTP Response Status Code Is 303 - Check Operation Occurrence Id Check HTTP Response Body Json Schema Is FmSubscription + Check HTTP Response Header Contains Location Check Postcondition Subscription Resource Returned in Location Header Is Available Retrieve a list of alarm subscriptions [Documentation] Test ID: 8.3.3.3.4 ... Test title: Retrieve a list of alarm subscriptions - ... Test objective: The objective is to retrieve the list of active subscriptions and perform a JSON schema and content validation of the returned fault management alarms subscription data structure. + ... Test objective: The objective is to retrieve the list of active subscriptions and perform a JSON schema validation of the returned fault management alarms subscription data structure. ... Pre-conditions: none ... Reference: clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 ... Config ID: Config_prod_NFV-MANO @@ -69,7 +69,7 @@ Retrieve a list of alarm subscriptions Retrieve a list of alarm subscriptions with filter [Documentation] Test ID: 8.3.3.3.5 ... Test title: Retrieve a list of alarm subscriptions with filter - ... Test objective: The objective is to retrieve the list of active subscriptions with filter and perform a JSON schema and content validation of the returned fault management alarms subscription data structure. + ... Test objective: The objective is to retrieve the list of active subscriptions with filter and perform a JSON schema validation of the returned fault management alarms subscription data structure. ... Pre-conditions: none ... Reference: clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 ... Config ID: Config_prod_NFV-MANO @@ -90,12 +90,12 @@ Get information about multiple alarms as a Paged Response ... Post-Conditions: none GET Subscriptions Check HTTP Response Status Code Is 200 - Check LINK in Header + Check HTTP Response Header Contains Link GET subscriptions - Bad Request Invalid attribute-based filtering parameters [Documentation] Test ID: 8.3.3.3.7 ... Test title: GET subscriptions - Bad Request Invalid attribute-based filtering parameters - ... Test objective: The objective is to retrieve the list of active subscriptions with Invalid attribute-based filtering parameters and perform a JSON schema and content validation of the returned problem details data structure. + ... Test objective: The objective is to retrieve the list of active subscriptions with Invalid attribute-based filtering parameters and perform a JSON schema validation of the returned problem details data structure. ... Pre-conditions: none ... Reference: clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 ... Config ID: Config_prod_NFV-MANO @@ -109,7 +109,7 @@ GET subscriptions - Bad Request Invalid attribute-based filtering parameters Get information about multiple alarms - Bad Request Response too Big [Documentation] Test ID: 8.3.3.3.8 ... Test title: Get information about multiple alarms - Bad Request Response too Big - ... Test objective: The objective is to try to retrieve information about active list subscription to check that response is too big and perform a JSON schema and content validation of the returned problem details data structure + ... Test objective: The objective is to try to retrieve information about active list subscription to check that response is too big and perform a JSON schema validation of the returned problem details data structure ... Pre-conditions: none ... Reference: Clause clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 ... Config ID: Config_prod_NFV-MANO diff --git a/SOL009/NFVMANOFaultManagement-API/environment/variables.txt b/SOL009/NFVMANOFaultManagement-API/environment/variables.txt index c58650bcc..fdb1ee9d3 100644 --- a/SOL009/NFVMANOFaultManagement-API/environment/variables.txt +++ b/SOL009/NFVMANOFaultManagement-API/environment/variables.txt @@ -7,8 +7,8 @@ ${CONTENT_TYPE} application/json ${ACCEPT} application/json ${ACCEPT_JSON} application/json ${AUTH_USAGE} 1 - -${WRONG_AUTHORIZATION} Bearer XXXXXWRONGXXXXX +${NEG_AUTHORIZATION} Bearer negativetoken +${BAD_AUTHORIZATION} Bear sometoken ${apiRoot} / ${apiName} nfvmanofm ${apiMajorVersion} v1 -- GitLab From 666e1a7cc0456baddd276e6a92cef8bab0129381 Mon Sep 17 00:00:00 2001 From: uihassan Date: Mon, 14 Sep 2020 11:10:38 +0500 Subject: [PATCH 17/22] templating, minor bugs fix and new testcases added --- .../NFVMANOFaultManagement-API/Alarms.robot | 7 ++--- .../FaultManagement-APIKeyword.robot | 14 ++++++---- .../IndividualAlarm.robot | 28 +++++++++++++------ .../IndividualSubscription.robot | 18 ++++++++++-- .../Subscriptions.robot | 2 -- .../jsons/fmSubscriptionRequest.json | 6 ++-- 6 files changed, 49 insertions(+), 26 deletions(-) diff --git a/SOL009/NFVMANOFaultManagement-API/Alarms.robot b/SOL009/NFVMANOFaultManagement-API/Alarms.robot index 1eedfd8b9..395a6c96c 100644 --- a/SOL009/NFVMANOFaultManagement-API/Alarms.robot +++ b/SOL009/NFVMANOFaultManagement-API/Alarms.robot @@ -59,7 +59,6 @@ Get information about multiple alarms with invalid attribute-based filtering par Check HTTP Response Status Code Is 400 Check HTTP Response Body Json Schema Is ProblemDetails - Get information about multiple alarms as a Paged Response [Documentation] Test ID: 8.3.3.1.5 ... Test title: Get information about multiple alarms as a Paged Response @@ -161,7 +160,7 @@ Get information about multiple alarms with malformed authorization token ... Test title: Get information about multiple alarms with malformed authorization token ... Test objective: The objective is to test that the retrieval of information about the alarm list fails when using malformed authorization token ... Pre-conditions: none - ... Reference: clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [3] v3.3.1 + ... Reference: clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: The NFV-MANO entity requires the usage of access tokens for authorizing the API requests. ... Post-Conditions: none @@ -173,7 +172,7 @@ Get information about multiple alarms without authorization token ... Test title: Get information about multiple alarms without authorization token ... Test objective: The objective is to test that the retrieval of information about the alarm list fails when omitting the authorization token ... Pre-conditions: none - ... Reference: clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [3] v3.3.1 + ... Reference: clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: The NFV-MANO entity requires the usage of access tokens for authorizing the API requests. ... Post-Conditions: none @@ -185,7 +184,7 @@ GET information about multiple alarms with expired or revoked authorization toke ... Test title: GET information about multiple alarms with expired or revoked authorization token ... Test objective: The objective is to test that the retrieval of information about the alarm list fails when using expired or revoked authorization token ... Pre-conditions: One or more Network Service Descriptors are onboarded in the NFVO - ... Reference: clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [3] v3.3.1 + ... Reference: clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: The NFV-MANO entity requires the usage of access tokens for authorizing the API requests. ... Post-Conditions: none diff --git a/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot b/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot index cc846559f..d2f872b07 100644 --- a/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot +++ b/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot @@ -1,5 +1,6 @@ *** Settings *** -Resource environment/variables.txt +Library String +Resource environment/variables.txt Library REST ${NFVMANO_SCHEMA}://${NFVMANO_HOST}:${NFVMANO_PORT} Library JSONLibrary Library JSONSchemaLibrary schemas/ @@ -173,7 +174,8 @@ POST Subscription Set Headers {"Accept":"${ACCEPT}"} Set Headers {"Content-Type": "${CONTENT_TYPE}"} Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} - ${body}= Get File jsons/fmSubscriptionRequest.json + ${template}= Get File jsons/fmSubscriptionRequest.json + ${body}= Format String ${template} callback_uri=${callback_uri} callback_endpoint=${callback_endpoint} Post ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions ${body} ${outputResponse}= Output response Set Global Variable @{response} ${outputResponse} @@ -196,7 +198,8 @@ POST Subscription Duplication permitted Set Headers {"Accept":"${ACCEPT}"} Set Headers {"Content-Type": "${CONTENT_TYPE}"} Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"} - ${body}= Get File jsons/fmSubscriptionRequest.json + ${template}= Get File jsons/fmSubscriptionRequest.json + ${body}= Format String ${template} callback_uri=${callback_uri} callback_endpoint=${callback_endpoint} Post ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions ${body} ${outputResponse}= Output response Set Global Variable @{response} ${outputResponse} @@ -209,14 +212,14 @@ Check Postcondition FaultManagement Subscription Is Set Set Suite Variable ${response} ${output} Check HTTP Response Status Code Is 200 - POST Subscription Duplication not permitted Log Create subscription instance by POST to ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions Pass Execution If ${NFVMANO_DUPLICATION} == 1 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 jsons/fmSubscriptionRequest.json + ${template}= Get File jsons/fmSubscriptionRequest.json + ${body}= Format String ${template} callback_uri=${callback_uri} callback_endpoint=${callback_endpoint} Post ${apiRoot}/${apiName}/${apiMajorVersion}/subscriptions ${body} ${outputResponse}= Output response Set Global Variable @{response} ${outputResponse} @@ -232,7 +235,6 @@ Check Postcondition Subscription Resource Returned in Location Header Is Availab ${result}= Output response body Validate Json FMSubscription.schema.json ${result} Log Validated FMSubscription schema - GET Subscriptions Log Get the list of active subscriptions diff --git a/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot b/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot index 23e3d369e..3493df3dd 100644 --- a/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot +++ b/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot @@ -34,9 +34,21 @@ Get information about an fault management individual alarm GET Fault Management Individual Alarm Check HTTP Response Status Code Is 200 Check HTTP Response Body Json Schema Is alarm + +Get information about an fault management individual alarm - Not Found + [Documentation] Test ID: 8.3.3.2.3 + ... Test title: Get information about an fault management individual alarm + ... Test objective: The objective is to test the retrieval of information about an individual alarm fails when the resource is not present. + ... Pre-conditions: none + ... Reference: clause 7.5.4.3.2 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + GET Fault Management Individual Alarm + Check HTTP Response Status Code Is 404 PUT Alarm - Method not implemented - [Documentation] Test ID: 8.3.3.2.3 + [Documentation] Test ID: 8.3.3.2.4 ... Test title: PUT Alarm - Method not implemented ... Test objective: he objective is to test that PUT method is not allowed to for fault management individual alarm on NFV-MANO ... Pre-conditions: The related alarm exists @@ -48,9 +60,9 @@ PUT Alarm - Method not implemented Check HTTP Response Status Code Is 405 PATCH Fault Management Individual Alarm - [Documentation] Test ID: 8.3.3.2.4 + [Documentation] Test ID: 8.3.3.2.5 ... Test title: PATCH Fault Management Individual Alarm - ... Test objective: The objective is to Modify an individual alarm resource and perform a JSON schema and content validation of the returned alarm data structure + ... Test objective: The objective is to Modify an individual alarm resource, and perform a JSON schema validation of the returned alarm data structure. ... Pre-conditions: The related alarm exists ... Reference: clause 7.5.4.3.4 - ETSI GS NFV-SOL 009 [5] V3.3.1 ... Config ID: Config_prod_NFV-MANO @@ -61,9 +73,9 @@ PATCH Fault Management Individual Alarm Check HTTP Response Body Json Schema Is AlarmModification Modify an individual alarm resource - Precondition failed - [Documentation] Test ID: 8.3.3.2.5 + [Documentation] Test ID: 8.3.3.2.6 ... Test title: Modify an individual alarm resource - Precondition failed - ... Test objective: The objective is to test that an individual alarm resource cannot be modified if the alarm is already in the state that is requested to be set + ... Test objective: The objective is to test that an individual alarm resource cannot be modified if the alarm is already in the state that is requested to be set, and perform a JSON schema validation of the returned data structure. ... Pre-conditions: The related alarm exists ... Reference: clause 7.5.4.3.4 - ETSI GS NFV-SOL 009 [5] V3.3.1 ... Config ID: Config_prod_NFV-MANO @@ -75,9 +87,9 @@ Modify an individual alarm resource - Precondition failed Check Postcondition fault management individual alarm exists Modify an individual alarm resource - Conflict - [Documentation] Test ID: 8.3.3.2.6 + [Documentation] Test ID: 8.3.3.2.7 ... Test title: Modify an individual alarm resource - Conflict - ... Test objective: The objective is to test that an individual alarm resource cannot be modified if the resource was modified by another entity + ... Test objective: The objective is to test that an individual alarm resource cannot be modified if the resource was modified by another entity , and perform a JSON schema validation of the returned data structure. ... Pre-conditions: The related alarm exists ... Reference: clause 7.5.4.3.4 - ETSI GS NFV-SOL 009 [5] V3.3.1 ... Config ID: Config_prod_NFV-MANO @@ -89,7 +101,7 @@ Modify an individual alarm resource - Conflict Check Postcondition fault management individual alarm exists DELETE Alarm - Method not implemented - [Documentation] Test ID: 8.3.3.2.7 + [Documentation] Test ID: 8.3.3.2.8 ... Test title: DELETE Alarm - Method not implemented ... Test objective: The objective is to test that DELETE method is not allowed to delete fault management individual alarm on NFV-MANO. ... Pre-conditions: none diff --git a/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot b/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot index 9d9b91a64..21d22e06a 100644 --- a/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot +++ b/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot @@ -31,9 +31,21 @@ Get Information about an individual subscription GET Individual Subscription Check HTTP Response Status Code Is 200 Check HTTP Response Body Json Schema Is FmSubscription + +Get Information about an individual subscription - Not Found + [Documentation] Test ID: 8.3.3.4.3 + ... Test title: Get Information about an individual subscription - Not Found + ... Test objective: The objective is to test the retrieval of individual subscription from NFV-MANO alarms fails when the resource is not present. + ... Pre-conditions: none + ... Reference: clause 7.5.6.3.2 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Config ID: Config_prod_NFV-MANO + ... Applicability: none + ... Post-Conditions: none + GET Individual Subscription + Check HTTP Response Status Code Is 404 PUT an individual subscription - Method not implemented - [Documentation] Test ID: 8.3.3.4.3 + [Documentation] Test ID: 8.3.3.4.4 ... Test title:PUT an individual subscription - Method not implemented ... Test objective: The objective is to test that PUT method is not allowed for fault management individual subscription on VNF ... Pre-conditions: none @@ -45,7 +57,7 @@ PUT an individual subscription - Method not implemented Check HTTP Response Status Code Is 405 PATCH an individual subscription - Method not implemented - [Documentation] Test ID: 8.3.3.4.4 + [Documentation] Test ID: 8.3.3.4.5 ... Test title:PATCH an individual subscription - Method not implemented ... Test objective: The objective is to test that PATCH method is not allowed for fault management individual subscription on VNF ... Pre-conditions: none @@ -57,7 +69,7 @@ PATCH an individual subscription - Method not implemented Check HTTP Response Status Code Is 405 DELETE an individual subscription - [Documentation] Test ID: 8.3.3.4.5 + [Documentation] Test ID: 8.3.3.4.6 ... Test title:DELETE an individual subscription ... Test objective: The objective is to test that DELETE method removes individual subscription on VNF ... Pre-conditions: The Subsbcription already exists diff --git a/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot b/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot index caec27420..7eee42b04 100644 --- a/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot +++ b/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot @@ -105,7 +105,6 @@ GET subscriptions - Bad Request Invalid attribute-based filtering parameters Check HTTP Response Status Code Is 400 Check HTTP Response Body Json Schema Is ProblemDetails - Get information about multiple alarms - Bad Request Response too Big [Documentation] Test ID: 8.3.3.3.8 ... Test title: Get information about multiple alarms - Bad Request Response too Big @@ -190,7 +189,6 @@ Get subscriptions with filter "filter.probableCauses" Check HTTP Response Body Json Schema Is FmSubscriptions Check PostCondition HTTP Response Body Subscriptions Matches the requested attribute-based filter "filter_probableCauses" - PUT subscriptions - Method not implemented [Documentation] Test ID: 8.3.3.3.14 ... Test title:PUT subscriptions - Method not implemented diff --git a/SOL009/NFVMANOFaultManagement-API/jsons/fmSubscriptionRequest.json b/SOL009/NFVMANOFaultManagement-API/jsons/fmSubscriptionRequest.json index 8d91c2b81..0e741d682 100644 --- a/SOL009/NFVMANOFaultManagement-API/jsons/fmSubscriptionRequest.json +++ b/SOL009/NFVMANOFaultManagement-API/jsons/fmSubscriptionRequest.json @@ -1,3 +1,3 @@ -{ - "callbackUri": "http://127.0.0.1/subscribe" -} \ No newline at end of file +{{ + "callbackUri": "{callback_uri}{callback_endpoint}" +}} \ No newline at end of file -- GitLab From 30a6877ddc5370c37dff0fa94b25a6060f257f8e Mon Sep 17 00:00:00 2001 From: uihassan Date: Mon, 14 Sep 2020 12:40:36 +0500 Subject: [PATCH 18/22] redundant post-conditions removed --- .../FaultManagement-APIKeyword.robot | 4 ---- SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot | 5 ++--- .../NFVMANOFaultManagement-API/IndividualSubscription.robot | 3 +-- 3 files changed, 3 insertions(+), 9 deletions(-) diff --git a/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot b/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot index d2f872b07..a83c15dd4 100644 --- a/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot +++ b/SOL009/NFVMANOFaultManagement-API/FaultManagement-APIKeyword.robot @@ -292,10 +292,6 @@ POST Individual Subscription ${outputResponse}= Output response Set Global Variable @{response} ${outputResponse} -Check Postcondition subscription not created - GET Individual Subscription - Check HTTP Response Status Code Is 404 - GET Individual Subscription log Trying to get information about an individual subscription Set Headers {"Accept":"${ACCEPT}"} diff --git a/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot b/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot index 3493df3dd..c1a4b258e 100644 --- a/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot +++ b/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot @@ -108,7 +108,6 @@ DELETE Alarm - Method not implemented ... Reference: clause 7.5.4.3.5 - ETSI GS NFV-SOL 009 [5] V3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none - ... Post-Conditions: The individual alarm still exists + ... Post-Conditions: none DELETE Fault Management Individual Alarm - Check HTTP Response Status Code Is 405 - Check Postcondition fault management individual alarm exists \ No newline at end of file + Check HTTP Response Status Code Is 405 \ No newline at end of file diff --git a/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot b/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot index 21d22e06a..116617884 100644 --- a/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot +++ b/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot @@ -14,10 +14,9 @@ Post Individual Subscription - Method not implemented ... Reference: clause 7.5.6.3.1 - ETSI GS NFV-SOL 009 [5] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none - ... Post-Conditions: subscription is not created + ... Post-Conditions: none POST Individual Subscription Check HTTP Response Status Code Is 405 - Check Postcondition subscription not created Get Information about an individual subscription [Documentation] Test ID: 8.3.3.4.2 -- GitLab From b212222ebff5fee85fe12f10b8b045706e518a85 Mon Sep 17 00:00:00 2001 From: Sana Zulfiqar Date: Mon, 14 Sep 2020 10:54:17 +0200 Subject: [PATCH 19/22] minor changes in pre-conditions --- SOL009/NFVMANOFaultManagement-API/Alarms.robot | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/SOL009/NFVMANOFaultManagement-API/Alarms.robot b/SOL009/NFVMANOFaultManagement-API/Alarms.robot index 395a6c96c..53ba9ed6e 100644 --- a/SOL009/NFVMANOFaultManagement-API/Alarms.robot +++ b/SOL009/NFVMANOFaultManagement-API/Alarms.robot @@ -103,7 +103,7 @@ GET information about multiple alarms with attribute-based filter "managedObject [Documentation] Test ID: 8.3.3.1.8 ... Test title: GET information about multiple alarms with attribute-based filter "managedObjectId" ... Test objective: The objective is to retrieve information about the alarm list with attribute filter "managedObjectId" - ... Pre-conditions: + ... Pre-conditions: none ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none @@ -117,7 +117,7 @@ GET information about multiple alarms with attribute-based filter "eventType" [Documentation] Test ID: 8.3.3.1.9 ... Test title: GET information about multiple alarms with attribute-based filter "eventType" ... Test objective: The objective is to retrieve information about the alarm list with attribute filter "eventType" - ... Pre-conditions: + ... Pre-conditions: none ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none @@ -165,7 +165,7 @@ Get information about multiple alarms with malformed authorization token ... Applicability: The NFV-MANO entity requires the usage of access tokens for authorizing the API requests. ... Post-Conditions: none GET Fault Management Alarms with malformed authorization token - Check HTTP Response Status Code Is 400 + Check HTTP Response Status Code Is 401 Get information about multiple alarms without authorization token [Documentation] Test ID: 8.3.3.1.13 @@ -226,5 +226,4 @@ DELETE Alarms - Method not implemented ... Post-Conditions: none DELETE Fault management Alarms Check HTTP Response Status Code Is 405 - Check Postcondition NFV-MANO fault management alarms Exists \ No newline at end of file -- GitLab From fec4f945d93b65bc6f73767f489d540ad9c076c2 Mon Sep 17 00:00:00 2001 From: Sana Zulfiqar Date: Mon, 14 Sep 2020 10:59:51 +0200 Subject: [PATCH 20/22] pre-condition updated --- SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot b/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot index c1a4b258e..d16f9b4b4 100644 --- a/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot +++ b/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot @@ -51,7 +51,7 @@ PUT Alarm - Method not implemented [Documentation] Test ID: 8.3.3.2.4 ... Test title: PUT Alarm - Method not implemented ... Test objective: he objective is to test that PUT method is not allowed to for fault management individual alarm on NFV-MANO - ... Pre-conditions: The related alarm exists + ... Pre-conditions: none ... Reference: clause 7.5.4.3.3 - ETSI GS NFV-SOL 009 [5] V3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none -- GitLab From 0905c2801d1fdb6141a4342ea44c7880446ee2f5 Mon Sep 17 00:00:00 2001 From: Giacomo Bernini Date: Thu, 22 Oct 2020 18:16:50 +0200 Subject: [PATCH 21/22] updated references --- .../NFVMANOFaultManagement-API/Alarms.robot | 34 +++++++++---------- .../ApiVersion.robot | 20 +++++------ .../IndividualAlarm.robot | 16 ++++----- .../IndividualSubscription.robot | 12 +++---- .../NotificationEndpoint.robot | 6 ++-- .../Subscriptions.robot | 32 ++++++++--------- 6 files changed, 60 insertions(+), 60 deletions(-) diff --git a/SOL009/NFVMANOFaultManagement-API/Alarms.robot b/SOL009/NFVMANOFaultManagement-API/Alarms.robot index 53ba9ed6e..c31d850cb 100644 --- a/SOL009/NFVMANOFaultManagement-API/Alarms.robot +++ b/SOL009/NFVMANOFaultManagement-API/Alarms.robot @@ -13,7 +13,7 @@ POST Alarms - Method not implemented ... Test title: POST Alarms - Method not implemented ... Test objective: The objective is to test that Post method is not allowed to create fault management alarms on NFV-MANO ... Pre-conditions: none - ... Reference: clause 7.5.3.3.1 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Reference: clause 7.5.3.3.1 - ETSI GS NFV-SOL 009 [6] V3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -25,7 +25,7 @@ Get information about multiple alarms ... Test title: Get information about multiple alarms ... Test objective: The objective is to retrieve information about the alarm list and perform a JSON schema of the returned alarms data structure ... Pre-conditions: none - ... Reference: clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Reference: clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [6] V3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -38,7 +38,7 @@ Get information about multiple alarms with filter ... Test title: Get information about multiple alarms with filter ... Test objective: The objective is to retrieve information about the alarm list and perform a JSON schema validation of the returned alarms data structure, and verify that the retrieved information matches the issued attribute-based filters ... Pre-conditions: none - ... Reference: clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Reference: clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [6] V3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -51,7 +51,7 @@ Get information about multiple alarms with invalid attribute-based filtering par ... Test title: Get information about multiple alarms with invalid attribute-based filtering parameters ... Test objective: The objective is to try to retrieve information about the alarm list with invalid filters and perform a JSON schema validation of the returned problem details data structure ... Pre-conditions: none - ... Reference: clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Reference: clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [6] V3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -64,7 +64,7 @@ Get information about multiple alarms as a Paged Response ... Test title: Get information about multiple alarms as a Paged Response ... Test objective: The objective is to retrieve information about the alarm list as a Paged Response. ... Pre-conditions: none - ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -77,7 +77,7 @@ Get information about multiple alarms - Bad Request Response too Big ... Test title: Get information about multiple alarms - Bad Request Response too Big ... Test objective: The objective is to try to retrieve information about the alarm list because response is too big and perform a JSON schema validation of the returned problem details data structure ... Pre-conditions: none - ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -90,7 +90,7 @@ GET information about alarms with attribute-based filter "id" ... Test title: GET information about alarms with attribute-based filter "id" ... Test objective: The objective is to retrieve information about the alarm list with alarm filter "id" ... Pre-conditions: none - ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -104,7 +104,7 @@ GET information about multiple alarms with attribute-based filter "managedObject ... Test title: GET information about multiple alarms with attribute-based filter "managedObjectId" ... Test objective: The objective is to retrieve information about the alarm list with attribute filter "managedObjectId" ... Pre-conditions: none - ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -118,7 +118,7 @@ GET information about multiple alarms with attribute-based filter "eventType" ... Test title: GET information about multiple alarms with attribute-based filter "eventType" ... Test objective: The objective is to retrieve information about the alarm list with attribute filter "eventType" ... Pre-conditions: none - ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -132,7 +132,7 @@ GET information about multiple alarms with attribute-based filter "perceivedSeve ... Test title: GET information about multiple alarms with attribute-based filter "perceivedSeverity" ... Test objective: The objective is to retrieve information about the alarm list with attribute filter "perceivedSeverity" ... Pre-conditions: none - ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -146,7 +146,7 @@ GET information about multiple alarms with attribute-based filter "probableCause ... Test title: GET information about multiple alarms with attribute-based filter "probableCause" ... Test objective: The objective is to retrieve information about the alarm list with attribute filter "probableCause" ... Pre-conditions: none - ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: Clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -160,7 +160,7 @@ Get information about multiple alarms with malformed authorization token ... Test title: Get information about multiple alarms with malformed authorization token ... Test objective: The objective is to test that the retrieval of information about the alarm list fails when using malformed authorization token ... Pre-conditions: none - ... Reference: clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: The NFV-MANO entity requires the usage of access tokens for authorizing the API requests. ... Post-Conditions: none @@ -172,7 +172,7 @@ Get information about multiple alarms without authorization token ... Test title: Get information about multiple alarms without authorization token ... Test objective: The objective is to test that the retrieval of information about the alarm list fails when omitting the authorization token ... Pre-conditions: none - ... Reference: clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: The NFV-MANO entity requires the usage of access tokens for authorizing the API requests. ... Post-Conditions: none @@ -184,7 +184,7 @@ GET information about multiple alarms with expired or revoked authorization toke ... Test title: GET information about multiple alarms with expired or revoked authorization token ... Test objective: The objective is to test that the retrieval of information about the alarm list fails when using expired or revoked authorization token ... Pre-conditions: One or more Network Service Descriptors are onboarded in the NFVO - ... Reference: clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: clause 7.5.3.3.2 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: The NFV-MANO entity requires the usage of access tokens for authorizing the API requests. ... Post-Conditions: none @@ -196,7 +196,7 @@ PUT Alarms - Method not implemented ... Test title: PUT Alarms - Method not implemented ... Test objective: The objective is to test that PUT method is not allowed to modify fault management alarms on NFV-MANO. ... Pre-conditions: none - ... Reference: clause 7.5.3.3.3 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Reference: clause 7.5.3.3.3 - ETSI GS NFV-SOL 009 [6] V3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -208,7 +208,7 @@ PATCH Alarms - Method not implemented ... Test title: PATCH Alarms - Method not implemented ... Test objective: The objective is to test that PATCH method is not allowed to modify fault management alarms on NFV-MANO. ... Pre-conditions: none - ... Reference: clause 7.5.3.3.4 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Reference: clause 7.5.3.3.4 - ETSI GS NFV-SOL 009 [6] V3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -220,7 +220,7 @@ DELETE Alarms - Method not implemented ... Test title: POST Alarms - Method not implemented ... Test objective: The objective is to test that DELETE method is not allowed for fault management alarms on NFV-MANO ... Pre-conditions: none - ... Reference: clause 7.5.3.3.5 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Reference: clause 7.5.3.3.5 - ETSI GS NFV-SOL 009 [6] V3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none diff --git a/SOL009/NFVMANOFaultManagement-API/ApiVersion.robot b/SOL009/NFVMANOFaultManagement-API/ApiVersion.robot index a02570f36..0dde1341d 100644 --- a/SOL009/NFVMANOFaultManagement-API/ApiVersion.robot +++ b/SOL009/NFVMANOFaultManagement-API/ApiVersion.robot @@ -11,7 +11,7 @@ POST API Version - Method not implemented ... Test title: POST API version - Method not implemented ... Test objective: The objective is to test that POST method is not implemented ... Pre-conditions: none - ... Reference: Clause 9.3.3.3.1 - ETSI GS NFV-SOL 013 v2.7.1 + ... Reference: Clause 9.3.3.3.1 - ETSI GS NFV-SOL 013 [5] ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -23,7 +23,7 @@ GET API Version ... Test title: GET API Version ... Test objective: The objective is to test that GET method successfully return ApiVersionInformation ... Pre-conditions: none - ... Reference: Clause 9.3.3.3.2 - ETSI GS NFV-SOL 013 v2.7.1 + ... Reference: Clause 9.3.3.3.2 - ETSI GS NFV-SOL 013 [5] ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -36,7 +36,7 @@ PUT API Version - Method not implemented ... Test title: PUT API Version - Method not implemented ... Test objective: The objective is to test that PUT method is not implemented ... Pre-conditions: none - ... Reference: Clause 9.3.3.3.3 - ETSI GS NFV-SOL 013 v2.7.1 + ... Reference: Clause 9.3.3.3.3 - ETSI GS NFV-SOL 013 [5] ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -48,7 +48,7 @@ PATCH API Version - Method not implemented ... Test title: PATCH API Version - Method not implemented ... Test objective: The objective is to test that PATCH method is not implemented ... Pre-conditions: none - ... Reference: Clause 9.3.3.3.4 - ETSI GS NFV-SOL 013 v2.7.1 + ... Reference: Clause 9.3.3.3.4 - ETSI GS NFV-SOL 013 [5] ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -60,7 +60,7 @@ DELETE API Version - Method not implemented ... Test title: DELETE API Version - Method not implemented ... Test objective: The objective is to test that DELETE method is not implemented ... Pre-conditions: none - ... Reference: Clause 9.3.3.3.5 - ETSI GS NFV-SOL 013 v2.7.1 + ... Reference: Clause 9.3.3.3.5 - ETSI GS NFV-SOL 013 [5] ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -72,7 +72,7 @@ POST API Version with apiMajorVerion - Method not implemented ... Test title: POST API version with apiMajorVerion - Method not implemented ... Test objective: The objective is to test that POST method is not implemented ... Pre-conditions: none - ... Reference: Clause 9.3.3.3.1 - ETSI GS NFV-SOL 013 v2.7.1 + ... Reference: Clause 9.3.3.3.1 - ETSI GS NFV-SOL 013 [5] ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -84,7 +84,7 @@ GET API Version with apiMajorVerion ... Test title: GET API Version with apiMajorVerion ... Test objective: The objective is to test that GET method successfully return ApiVersionInformation ... Pre-conditions: none - ... Reference: Clause 9.3.3.3.2 - ETSI GS NFV-SOL 013 v2.7.1 + ... Reference: Clause 9.3.3.3.2 - ETSI GS NFV-SOL 013 [5] ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -97,7 +97,7 @@ PUT API Version with apiMajorVerion - Method not implemented ... Test title: PUT API Version with apiMajorVerion - Method not implemented ... Test objective: The objective is to test that PUT method is not implemented ... Pre-conditions: none - ... Reference: Clause 9.3.3.3.3 - ETSI GS NFV-SOL 013 v2.7.1 + ... Reference: Clause 9.3.3.3.3 - ETSI GS NFV-SOL 013 [5] ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -109,7 +109,7 @@ PATCH API Version with apiMajorVerion - Method not implemented ... Test title: PATCH API Version with apiMajorVerion - Method not implemented ... Test objective: The objective is to test that PATCH method is not implemented ... Pre-conditions: none - ... Reference: Clause 9.3.3.3.4 - ETSI GS NFV-SOL 013 v2.7.1 + ... Reference: Clause 9.3.3.3.4 - ETSI GS NFV-SOL 013 [5] ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -121,7 +121,7 @@ DELETE API Version with apiMajorVerion - Method not implemented ... Test title: DELETE API Version with apiMajorVerion - Method not implemented ... Test objective: The objective is to test that DELETE method is not implemented ... Pre-conditions: none - ... Reference: Clause 9.3.3.3.5 - ETSI GS NFV-SOL 013 v2.7.1 + ... Reference: Clause 9.3.3.3.5 - ETSI GS NFV-SOL 013 [5] ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none diff --git a/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot b/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot index d16f9b4b4..49d8d806e 100644 --- a/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot +++ b/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot @@ -15,7 +15,7 @@ POST Alarm - Method not implemented ... Test title: POST Alarm - Method not implemented ... Test objective: The objective is to test that Post method is not allowed to create fault management individual alarm on NFV-MANO ... Pre-conditions: none - ... Reference: clause 7.5.4.3.1 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Reference: clause 7.5.4.3.1 - ETSI GS NFV-SOL 009 [6] V3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -27,7 +27,7 @@ Get information about an fault management individual alarm ... Test title: Get information about an fault management individual alarm ... Test objective: The objective is to retrieve information about an individual alarm and perform a JSON schema and content validation of the returned alarm data structure ... Pre-conditions: The related alarm exists - ... Reference: clause 7.5.4.3.2 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Reference: clause 7.5.4.3.2 - ETSI GS NFV-SOL 009 [6] V3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -40,7 +40,7 @@ Get information about an fault management individual alarm - Not Found ... Test title: Get information about an fault management individual alarm ... Test objective: The objective is to test the retrieval of information about an individual alarm fails when the resource is not present. ... Pre-conditions: none - ... Reference: clause 7.5.4.3.2 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Reference: clause 7.5.4.3.2 - ETSI GS NFV-SOL 009 [6] V3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -52,7 +52,7 @@ PUT Alarm - Method not implemented ... Test title: PUT Alarm - Method not implemented ... Test objective: he objective is to test that PUT method is not allowed to for fault management individual alarm on NFV-MANO ... Pre-conditions: none - ... Reference: clause 7.5.4.3.3 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Reference: clause 7.5.4.3.3 - ETSI GS NFV-SOL 009 [6] V3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -64,7 +64,7 @@ PATCH Fault Management Individual Alarm ... Test title: PATCH Fault Management Individual Alarm ... Test objective: The objective is to Modify an individual alarm resource, and perform a JSON schema validation of the returned alarm data structure. ... Pre-conditions: The related alarm exists - ... Reference: clause 7.5.4.3.4 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Reference: clause 7.5.4.3.4 - ETSI GS NFV-SOL 009 [6] V3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: Alarm is modified. @@ -77,7 +77,7 @@ Modify an individual alarm resource - Precondition failed ... Test title: Modify an individual alarm resource - Precondition failed ... Test objective: The objective is to test that an individual alarm resource cannot be modified if the alarm is already in the state that is requested to be set, and perform a JSON schema validation of the returned data structure. ... Pre-conditions: The related alarm exists - ... Reference: clause 7.5.4.3.4 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Reference: clause 7.5.4.3.4 - ETSI GS NFV-SOL 009 [6] V3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: Alarm is not modified. @@ -91,7 +91,7 @@ Modify an individual alarm resource - Conflict ... Test title: Modify an individual alarm resource - Conflict ... Test objective: The objective is to test that an individual alarm resource cannot be modified if the resource was modified by another entity , and perform a JSON schema validation of the returned data structure. ... Pre-conditions: The related alarm exists - ... Reference: clause 7.5.4.3.4 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Reference: clause 7.5.4.3.4 - ETSI GS NFV-SOL 009 [6] V3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: Alarm is not modified. @@ -105,7 +105,7 @@ DELETE Alarm - Method not implemented ... Test title: DELETE Alarm - Method not implemented ... Test objective: The objective is to test that DELETE method is not allowed to delete fault management individual alarm on NFV-MANO. ... Pre-conditions: none - ... Reference: clause 7.5.4.3.5 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Reference: clause 7.5.4.3.5 - ETSI GS NFV-SOL 009 [6] V3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none diff --git a/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot b/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot index 116617884..b4022daf4 100644 --- a/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot +++ b/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot @@ -11,7 +11,7 @@ Post Individual Subscription - Method not implemented ... Test title: Post Individual Subscription - Method not implemented ... Test objective: The objective is to test that POST method is not allowed for fault management subscription on NFV-MANO ... Pre-conditions: none - ... Reference: clause 7.5.6.3.1 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: clause 7.5.6.3.1 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -23,7 +23,7 @@ Get Information about an individual subscription ... Test title: Get Information about an individual subscription ... Test objective: The objective is to read an individual subscription from NFV-MANO alarms subscribed by the client and perform a JSON schema and content validation of the returned fault management individual subscription data structure ... Pre-conditions: The subscription with the given id exists - ... Reference: clause 7.5.6.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: clause 7.5.6.3.2 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -36,7 +36,7 @@ Get Information about an individual subscription - Not Found ... Test title: Get Information about an individual subscription - Not Found ... Test objective: The objective is to test the retrieval of individual subscription from NFV-MANO alarms fails when the resource is not present. ... Pre-conditions: none - ... Reference: clause 7.5.6.3.2 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Reference: clause 7.5.6.3.2 - ETSI GS NFV-SOL 009 [6] V3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -48,7 +48,7 @@ PUT an individual subscription - Method not implemented ... Test title:PUT an individual subscription - Method not implemented ... Test objective: The objective is to test that PUT method is not allowed for fault management individual subscription on VNF ... Pre-conditions: none - ... Reference: clause 7.5.6.3.3 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: clause 7.5.6.3.3 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -60,7 +60,7 @@ PATCH an individual subscription - Method not implemented ... Test title:PATCH an individual subscription - Method not implemented ... Test objective: The objective is to test that PATCH method is not allowed for fault management individual subscription on VNF ... Pre-conditions: none - ... Reference: clause 7.5.6.3.4 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: clause 7.5.6.3.4 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -72,7 +72,7 @@ DELETE an individual subscription ... Test title:DELETE an individual subscription ... Test objective: The objective is to test that DELETE method removes individual subscription on VNF ... Pre-conditions: The Subsbcription already exists - ... Reference: clause 7.5.6.3.5 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: clause 7.5.6.3.5 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: subscription is not deleted diff --git a/SOL009/NFVMANOFaultManagement-API/NotificationEndpoint.robot b/SOL009/NFVMANOFaultManagement-API/NotificationEndpoint.robot index ed61029e8..47640fb7c 100644 --- a/SOL009/NFVMANOFaultManagement-API/NotificationEndpoint.robot +++ b/SOL009/NFVMANOFaultManagement-API/NotificationEndpoint.robot @@ -14,7 +14,7 @@ NFV-MANO Fault Alarm Notification ... Test title: NFV-MANO Fault Alarm Notification ... Test objective: The objective is to test the dispatch of NFV-MANO Fault Alarm Notification when a resource within an NFV-MANO instance fails, and perform a JSON schema and content validation of the delivered notification. The action that triggers the notification under test is an explicit test step, but it is not performed by the test system. ... Pre-conditions: A NFV-MANO instance is instantiated, and a subscription for fault alarm notifications is available. - ... Reference: clause 7.5.7.3.1 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Reference: clause 7.5.7.3.1 - ETSI GS NFV-SOL 009 [6] V3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -27,7 +27,7 @@ NFV-MANO Fault Alarm Cleared Notification ... Test title: NFV-MANO Fault Alarm Cleared Notification ... Test objective: The objective is to test the dispatch of NFV-MANO Fault Alarm Cleared Notification when a faulty resource within an NFV-MANO instance is cleared, and perform a JSON schema and content validation of the delivered notification. The action that triggers the notification under test is an explicit test step, but it is not performed by the test system. ... Pre-conditions: A NFV-MANO instance is instantiated, a virtualised resource is in faulty state, and a subscription for fault alarm cleared notifications is available. - ... Reference: clause 7.5.7.3.1 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Reference: clause 7.5.7.3.1 - ETSI GS NFV-SOL 009 [6] V3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -40,7 +40,7 @@ NFV-MANO Fault Alarm List Rebuilt Notification ... Test title: NFV-MANO Fault Alarm List Rebuilt Notification ... Test objective: The objective is to test the dispatch of NFV-MANO Fault Alarm List Rebuilt Notification when the NFV-MANO decides to rebuild the list of its NFV-MANO alarms, e.g. due to a corruption in the alarm storage, and perform a JSON schema and content validation of the delivered notification. The action that triggers the notification under test is an explicit test step, but it is not performed by the test system. ... Pre-conditions: A NFV-MANO instance is instantiated, one or more virtualised resource are in faulty state, and a subscription for fault alarm list rebuilt notifications is available. - ... Reference: clause 7.5.7.3.1 - ETSI GS NFV-SOL 009 [5] V3.3.1 + ... Reference: clause 7.5.7.3.1 - ETSI GS NFV-SOL 009 [6] V3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none diff --git a/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot b/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot index 7eee42b04..cfa5851cc 100644 --- a/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot +++ b/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot @@ -13,7 +13,7 @@ Create a new Fault Management alarm subscription ... Test title: Create a new fault management alarm subscription ... Test objective: The objective is to create a new fault management alarm subscription and perform a JSON schema validation of the returned fault management alarms subscription data structure ... Pre-conditions: No subscription with the same filter and callbackUri exists - ... Reference: clause 7.5.5.3.1 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: clause 7.5.5.3.1 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: subscription is created @@ -28,7 +28,7 @@ Create a new alarm subscription - DUPLICATION ... Test title: Create a new alarm subscription - DUPLICATION ... Test objective: The objective is to create a new subscription with the NFV-MANO allowing duplication and perform a JSON schema validation of the returned fault management alarms subscription data structure. ... Pre-conditions: subscription with the same filter and callbackUri exists - ... Reference: clause 7.5.5.3.1 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: clause 7.5.5.3.1 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: the NFV-MANO allows creating a subscription resource if another subscription resource with the same filter and callbackUri already exists ... Post-Conditions: duplicated subscription is created @@ -43,7 +43,7 @@ Create a new alarm subscription - NO DUPLICATION ... Test title: Create a new alarm subscription - NO DUPLICATION ... Test objective: The objective is to create a new subscription with the NFV-MANO not allowing duplication and perform a JSON schema validation of the returned fault management alarms subscription data structure. ... Pre-conditions: subscription with the same filter and callbackUri exists - ... Reference: clause 7.5.5.3.1 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: clause 7.5.5.3.1 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: the NFV-MANO decides to not create a duplicate subscription resource ... Post-Conditions: duplicated subscription is not created @@ -58,7 +58,7 @@ Retrieve a list of alarm subscriptions ... Test title: Retrieve a list of alarm subscriptions ... Test objective: The objective is to retrieve the list of active subscriptions and perform a JSON schema validation of the returned fault management alarms subscription data structure. ... Pre-conditions: none - ... Reference: clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: noe @@ -71,7 +71,7 @@ Retrieve a list of alarm subscriptions with filter ... Test title: Retrieve a list of alarm subscriptions with filter ... Test objective: The objective is to retrieve the list of active subscriptions with filter and perform a JSON schema validation of the returned fault management alarms subscription data structure. ... Pre-conditions: none - ... Reference: clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -84,7 +84,7 @@ Get information about multiple alarms as a Paged Response ... Test title: Get information about multiple alarms as a Paged Response ... Test objective: The objective is to retrieve information about active list subscriptions as a Paged Response ... Pre-conditions: none - ... Reference: Clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: Clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -97,7 +97,7 @@ GET subscriptions - Bad Request Invalid attribute-based filtering parameters ... Test title: GET subscriptions - Bad Request Invalid attribute-based filtering parameters ... Test objective: The objective is to retrieve the list of active subscriptions with Invalid attribute-based filtering parameters and perform a JSON schema validation of the returned problem details data structure. ... Pre-conditions: none - ... Reference: clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -110,7 +110,7 @@ Get information about multiple alarms - Bad Request Response too Big ... Test title: Get information about multiple alarms - Bad Request Response too Big ... Test objective: The objective is to try to retrieve information about active list subscription to check that response is too big and perform a JSON schema validation of the returned problem details data structure ... Pre-conditions: none - ... Reference: Clause clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: Clause clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -123,7 +123,7 @@ GET Subscription with attribute-based filter "id" ... Test title: GET Subscription with attribute-based filter "id" ... Test objective: The objective is to retrieve the list of active subscriptions with filter "id" ... Pre-conditions: - ... Reference: Clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: Clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: ... Post-Conditions: @@ -138,7 +138,7 @@ Get subscriptions with filter "filter.notificationTypes" ... Test title: GET Subscription with attribute-based filter "filter.notificationTypes" ... Test objective: The objective is to retrieve the list of active subscriptions with filter "filter.notificationTypes" ... Pre-conditions: - ... Reference: Clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: Clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: ... Post-Conditions: @@ -152,7 +152,7 @@ Get subscriptions with filter "filter.perceivedSeverities" ... Test title: GET Subscription with attribute-based filter "filter.perceivedSeverities" ... Test objective: The objective is to retrieve the list of active subscriptions with filter "filter.perceivedSeverities" ... Pre-conditions: - ... Reference: Clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: Clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: ... Post-Conditions: @@ -166,7 +166,7 @@ Get subscriptions with filter "filter.eventTypes" ... Test title: GET Subscription with attribute-based filter "filter.eventTypes" ... Test objective: The objective is to retrieve the list of active subscriptions with filter "filter.eventTypes" ... Pre-conditions: - ... Reference: Clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: Clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: ... Post-Conditions: @@ -180,7 +180,7 @@ Get subscriptions with filter "filter.probableCauses" ... Test title: GET Subscription with attribute-based filter "filter.probableCauses" ... Test objective: The objective is to retrieve the list of active subscriptions with filter "filter.probableCauses" ... Pre-conditions: - ... Reference: Clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: Clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: ... Post-Conditions: @@ -194,7 +194,7 @@ PUT subscriptions - Method not implemented ... Test title:PUT subscriptions - Method not implemented ... Test objective: The objective is to test that PUT method is not allowed to for fault management subscriptions on VNF ... Pre-conditions: none - ... RReference: clause 7.5.5.3.3 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... RReference: clause 7.5.5.3.3 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -206,7 +206,7 @@ PATCH subscriptions - Method not implemented ... Test title: PATCH subscriptions - Method not implemented ... Test objective: The objective is to test that PATCH method is not allowed to for fault management subscriptions on VNF ... Pre-conditions: none - ... Reference: clause 7.5.5.3.4 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: clause 7.5.5.3.4 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: none @@ -218,7 +218,7 @@ DELETE subscriptions - Method not implemented ... Test title: DELETE subscriptions - Method not implemented ... Test objective: The objective is to test that DELETE method is not allowed to for fault management subscriptions on VNF ... Pre-conditions: none - ... Reference: clause 7.5.5.3.5 - ETSI GS NFV-SOL 009 [5] v3.3.1 + ... Reference: clause 7.5.5.3.5 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none ... Post-Conditions: subscription is not deleted -- GitLab From 193dfba266f2ed8956d4ceea9ab8af25d37267c4 Mon Sep 17 00:00:00 2001 From: uihassan Date: Mon, 26 Oct 2020 16:11:25 +0500 Subject: [PATCH 22/22] minor bugs fix added --- .../NFVMANOFaultManagement-API/Alarms.robot | 1 - .../IndividualAlarm.robot | 17 +++++---- .../IndividualSubscription.robot | 4 +-- .../Subscriptions.robot | 35 +++++++++---------- 4 files changed, 27 insertions(+), 30 deletions(-) diff --git a/SOL009/NFVMANOFaultManagement-API/Alarms.robot b/SOL009/NFVMANOFaultManagement-API/Alarms.robot index c31d850cb..4ac515cb8 100644 --- a/SOL009/NFVMANOFaultManagement-API/Alarms.robot +++ b/SOL009/NFVMANOFaultManagement-API/Alarms.robot @@ -6,7 +6,6 @@ Library JSONLibrary Library JSONSchemaLibrary schemas/ Library OperatingSystem - *** Test Cases *** POST Alarms - Method not implemented [Documentation] Test ID: 8.3.3.1.1 diff --git a/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot b/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot index 49d8d806e..5a38fd5f5 100644 --- a/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot +++ b/SOL009/NFVMANOFaultManagement-API/IndividualAlarm.robot @@ -7,12 +7,10 @@ Library JSONLibrary Library JSONSchemaLibrary schemas/ Library DependencyLibrary - - *** Test Cases *** -POST Alarm - Method not implemented +POST Individual Alarm - Method not implemented [Documentation] Test ID: 8.3.3.2.1 - ... Test title: POST Alarm - Method not implemented + ... Test title: POST Individual Alarm - Method not implemented ... Test objective: The objective is to test that Post method is not allowed to create fault management individual alarm on NFV-MANO ... Pre-conditions: none ... Reference: clause 7.5.4.3.1 - ETSI GS NFV-SOL 009 [6] V3.3.1 @@ -46,11 +44,12 @@ Get information about an fault management individual alarm - Not Found ... Post-Conditions: none GET Fault Management Individual Alarm Check HTTP Response Status Code Is 404 + Check HTTP Response Body Json Schema Is ProblemDetails -PUT Alarm - Method not implemented +PUT Individual Alarm - Method not implemented [Documentation] Test ID: 8.3.3.2.4 - ... Test title: PUT Alarm - Method not implemented - ... Test objective: he objective is to test that PUT method is not allowed to for fault management individual alarm on NFV-MANO + ... Test title: PUT Individual Alarm - Method not implemented + ... Test objective: The objective is to test that PUT method is not allowed to for fault management individual alarm on NFV-MANO ... Pre-conditions: none ... Reference: clause 7.5.4.3.3 - ETSI GS NFV-SOL 009 [6] V3.3.1 ... Config ID: Config_prod_NFV-MANO @@ -100,9 +99,9 @@ Modify an individual alarm resource - Conflict Check HTTP Response Body Json Schema Is ProblemDetails Check Postcondition fault management individual alarm exists -DELETE Alarm - Method not implemented +DELETE Individual Alarm - Method not implemented [Documentation] Test ID: 8.3.3.2.8 - ... Test title: DELETE Alarm - Method not implemented + ... Test title: DELETE Individual Alarm - Method not implemented ... Test objective: The objective is to test that DELETE method is not allowed to delete fault management individual alarm on NFV-MANO. ... Pre-conditions: none ... Reference: clause 7.5.4.3.5 - ETSI GS NFV-SOL 009 [6] V3.3.1 diff --git a/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot b/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot index b4022daf4..a957c5e34 100644 --- a/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot +++ b/SOL009/NFVMANOFaultManagement-API/IndividualSubscription.robot @@ -75,7 +75,7 @@ DELETE an individual subscription ... Reference: clause 7.5.6.3.5 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none - ... Post-Conditions: subscription is not deleted + ... Post-Conditions: subscription is deleted DELETE Individual Subscription Check HTTP Response Status Code Is 204 - Check Individual Subscription deleted + Check Individual Subscription deleted \ No newline at end of file diff --git a/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot b/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot index cfa5851cc..d9f55b948 100644 --- a/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot +++ b/SOL009/NFVMANOFaultManagement-API/Subscriptions.robot @@ -45,7 +45,7 @@ Create a new alarm subscription - NO DUPLICATION ... Pre-conditions: subscription with the same filter and callbackUri exists ... Reference: clause 7.5.5.3.1 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO - ... Applicability: the NFV-MANO decides to not create a duplicate subscription resource + ... Applicability: the NFV-MANO does not allow to create a duplicate subscription resource ... Post-Conditions: duplicated subscription is not created POST Subscription Duplication not permitted Check HTTP Response Status Code Is 303 @@ -122,26 +122,25 @@ GET Subscription with attribute-based filter "id" [Documentation] Test ID: 8.3.3.3.9 ... Test title: GET Subscription with attribute-based filter "id" ... Test objective: The objective is to retrieve the list of active subscriptions with filter "id" - ... Pre-conditions: + ... Pre-conditions: none ... Reference: Clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO - ... Applicability: - ... Post-Conditions: + ... Applicability: none + ... Post-Conditions: none Get subscriptions with filter "id" Check HTTP Response Status Code Is 200 Check HTTP Response Body Json Schema Is FmSubscription Check PostCondition HTTP Response Body Subscription Matches the requested attribute-based filter "id" - Get subscriptions with filter "filter.notificationTypes" [Documentation] Test ID: 8.3.3.3.10 ... Test title: GET Subscription with attribute-based filter "filter.notificationTypes" ... Test objective: The objective is to retrieve the list of active subscriptions with filter "filter.notificationTypes" - ... Pre-conditions: + ... Pre-conditions: none ... Reference: Clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO - ... Applicability: - ... Post-Conditions: + ... Applicability: none + ... Post-Conditions: none Get subscriptions with filter "filter_notificationTypes" Check HTTP Response Status Code Is 200 Check HTTP Response Body Json Schema Is FmSubscriptions @@ -151,11 +150,11 @@ Get subscriptions with filter "filter.perceivedSeverities" [Documentation] Test ID: 8.3.3.3.11 ... Test title: GET Subscription with attribute-based filter "filter.perceivedSeverities" ... Test objective: The objective is to retrieve the list of active subscriptions with filter "filter.perceivedSeverities" - ... Pre-conditions: + ... Pre-conditions: none ... Reference: Clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO - ... Applicability: - ... Post-Conditions: + ... Applicability: none + ... Post-Conditions: none Get subscriptions with filter "filter_perceivedSeverities" Check HTTP Response Status Code Is 200 Check HTTP Response Body Json Schema Is FmSubscriptions @@ -165,11 +164,11 @@ Get subscriptions with filter "filter.eventTypes" [Documentation] Test ID: 8.3.3.3.12 ... Test title: GET Subscription with attribute-based filter "filter.eventTypes" ... Test objective: The objective is to retrieve the list of active subscriptions with filter "filter.eventTypes" - ... Pre-conditions: + ... Pre-conditions: none ... Reference: Clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO - ... Applicability: - ... Post-Conditions: + ... Applicability: none + ... Post-Conditions: none Get subscriptions with filter "filter_eventTypes" Check HTTP Response Status Code Is 200 Check HTTP Response Body Json Schema Is FmSubscriptions @@ -179,11 +178,11 @@ Get subscriptions with filter "filter.probableCauses" [Documentation] Test ID: 8.3.3.3.13 ... Test title: GET Subscription with attribute-based filter "filter.probableCauses" ... Test objective: The objective is to retrieve the list of active subscriptions with filter "filter.probableCauses" - ... Pre-conditions: + ... Pre-conditions: none ... Reference: Clause 7.5.5.3.2 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO - ... Applicability: - ... Post-Conditions: + ... Applicability: none + ... Post-Conditions: none Get subscriptions with filter "filter_probableCauses" Check HTTP Response Status Code Is 200 Check HTTP Response Body Json Schema Is FmSubscriptions @@ -221,6 +220,6 @@ DELETE subscriptions - Method not implemented ... Reference: clause 7.5.5.3.5 - ETSI GS NFV-SOL 009 [6] v3.3.1 ... Config ID: Config_prod_NFV-MANO ... Applicability: none - ... Post-Conditions: subscription is not deleted + ... Post-Conditions: none DELETE Subscriptions Check HTTP Response Status Code Is 405 \ No newline at end of file -- GitLab