Skip to content
GitLab
Commit 3950867d authored by Giacomo Bernini's avatar Giacomo Bernini
Browse files

Merge branch '2.6.1-dev' into 'master' 

NFV API conformance tests for SOL002/3/5 v2.6.1

See merge request !108
parents 3668ac55 91d686b7
Hide whitespace changes
Inline Side-by-side
.gitignore
View file @ 3950867d
......@@ -3,3 +3,4 @@
/red.xml
build/
dist/
/libspecs/
LICENSE
View file @ 3950867d
Copyright 2019 ETSI
Copyright 2019-2020 ETSI
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
......
README.md
View file @ 3950867d
# NFV API Conformance Test Specification (NFV-TST 010)
This repository hosts the NFV API Conformance test specification for
the APIs defined in ETSI NFV GS [SOL002](https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/02.04.01_60/gs_NFV-SOL002v020401p.pdf), [SOL003](https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/02.04.01_60/gs_NFV-SOL003v020401p.pdf), [SOL005](http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/005/02.04.01_60/gs_NFV-SOL005v020401p.pdf), in their versions v2.4.1.
the APIs defined in ETSI NFV GS [SOL002](https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/02.06.01_60/gs_NFV-SOL002v020601p.pdf), [SOL003](https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/02.06.01_60/gs_NFV-SOL003v020601p.pdf), [SOL005](https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/005/02.06.01_60/gs_NFV-SOL005v020601p.pdf), in their versions v2.6.1.
More information and download is available at [DGS/NFV-TST010ed261](https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=58428).
More information and download is available at [DGS/NFV-TST010](https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=54031).
## Overview
......
SOL002/README.md
View file @ 3950867d
......@@ -2,7 +2,7 @@
This folder includes the NFV API conformance test descriptions for NFV SOL002 APIs.
The reference spec version is v2.4.1: https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/02.04.01_60/gs_NFV-SOL002v020401p.pdf
The reference spec version is v2.6.1: https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/02.06.01_60/gs_NFV-SOL002v020601p.pdf
## License
......
SOL002/VNFConfiguration-API/ApiVersion.robot 0 → 100644
View file @ 3950867d
*** Settings ***
Resource environment/variables.txt
Library REST ${EM-VNF_SCHEMA}://${EM-VNF_HOST}:${EM-VNF_PORT} ssl_verify=false
Library DependencyLibrary
Library JSONLibrary
Library JSONSchemaLibrary schemas/
*** Test Cases ***
POST API Version - Method not implemented
[Documentation] Test ID: 6.3.1.2.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.6.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
POST API Version
Check HTTP Response Status Code Is 405
GET API Version
[Documentation] Test ID: 6.3.1.2.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.6.1
... Config ID: Config_prod_VNFM
... 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: 6.3.1.2.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.6.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
PUT API Version
Check HTTP Response Status Code Is 405
PATCH API Version - Method not implemented
[Documentation] Test ID: 6.3.1.2.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.6.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
PATCH API Version
Check HTTP Response Status Code Is 405
DELETE API Version - Method not implemented
[Documentation] Test ID: 6.3.1.2.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.6.1
... Config ID: Config_prod_VNFM
... 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: 6.3.1.2.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.6.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
POST API Version
Check HTTP Response Status Code Is 405
GET API Version with apiMajorVerion
[Documentation] Test ID: 6.3.1.2.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.6.1
... Config ID: Config_prod_VNFM
... 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: 6.3.1.2.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.6.1
... Config ID: Config_prod_VNFM
... 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: 6.3.1.2.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.6.1
... Config ID: Config_prod_VNFM
... 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: 6.3.1.2.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.6.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
DELETE API Version
Check HTTP Response Status Code Is 405
*** Keywords ***
POST API Version
Set Headers {"Accept":"${ACCEPT}"}
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}"}
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}"}
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}"}
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}"}
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}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Post ${apiRoot}/${apiName}/v1/api_version
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
GET API Version with apiMajorVersion
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Get ${apiRoot}/${apiName}/v1/api_version
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
PUT API Version with apiMajorVersion
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Put ${apiRoot}/${apiName}/v1/api_version
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
PATCH API Version with apiMajorVersion
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Patch ${apiRoot}/${apiName}/v1/api_version
${outputResponse}= Output response
Set Global Variable ${response} ${outputResponse}
DELETE API Version with apiMajorVersion
Set Headers {"Accept":"${ACCEPT}"}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
Delete ${apiRoot}/${apiName}/v1/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
\ No newline at end of file
SOL002/VNFConfiguration-API/Configuration.robot
View file @ 3950867d
......@@ -12,7 +12,7 @@ Set new VNF Configuration
... Test title: Set a new VNF Configuration
... Test objective: The objective is to test the creation of a new VNF configuration and perform a JSON schema validation of the returned configuration data structure
... Pre-conditions: A VNF instance is instantiated
... Reference: clause 9.4.2.3.4 - ETSI GS NFV-SOL 002 [2] v2.4.1
... Reference: Clause 9.4.2.3.4 - ETSI GS NFV-SOL 002 [2] v2.6.1
... Config ID: Config_prod_VE
... Applicability: The VNF supports the generation of HTTP Etag opaque identifiers
... Post-Conditions: The configuration is successfully set in the VNF and it matches the issued configuration
......@@ -28,7 +28,7 @@ Get information about a VNF configuration
... Test title: Get information about a VNF configuration
... Test objective: The objective is to test the retrieval of an existing VNF instance configuration and perform a JSON schema validation of the collected configuration data structure
... Pre-conditions: A VNF instance is instantiated. The VNF instance is already configured.
... Reference: clause 9.4.2.3.2 - ETSI GS NFV-SOL 002 [2] v2.4.1
... Reference: Clause 9.4.2.3.2 - ETSI GS NFV-SOL 002 [2] v2.6.1
... Config ID: Config_prod_VE
... Applicability: none
... Post-Conditions: none
......@@ -42,7 +42,7 @@ Get information about a VNF configuration with HTTP Etag
... Test title: Get information about a VNF configuration with HTTP Etag
... Test objective: The objective is to test the retrieval of an existing VNF instance configuration, check the generation by the VNF of an HTTP Etag opaque identifier, and perform a JSON schema validation of the collected configuration data structure
... Pre-conditions: A VNF instance is instantiated. The VNF instance is already configured
... Reference: clause 9.4.2.3.2 - ETSI GS NFV-SOL 002 [2] v2.4.1
... Reference: Clause 9.4.2.3.2 - ETSI GS NFV-SOL 002 [2] v2.6.1
... Config ID: Config_prod_VE
... Applicability: The VNF supports the generation of HTTP Etag opaque identifiers
... Post-Conditions: none
......@@ -57,7 +57,7 @@ Set new VNF Configuration - HTTP Etag precondition unsuccessful
... Test title: Set a new VNF Configuration - HTTP Etag precondition unsuccessful
... Test objective: The objective is to test the unsuccess in setting a duplication of VNF configuration identified by an already used HTTP Etag identifier. The test also checks the JSON schema of the unsuccessful operation HTTP response.
... Pre-conditions: A VNF instance is instantiated. The VNF instance is already configured (Test ID 6.3.1.1.1) with a given HTTP Etag identifier.
... Reference: clause 9.4.2.3.4 - ETSI GS NFV-SOL 002 [2] v2.4.1
... Reference: Clause 9.4.2.3.4 - ETSI GS NFV-SOL 002 [2] v2.6.1
... Config ID: Config_prod_VE
... Applicability: The VNF supports the generation of HTTP Etag opaque identifiers
... Post-Conditions: The VNF configuration is not modified by the unsuccessful operation and it matches the configuration issued in Test ID 6.3.1.1.1
......@@ -71,7 +71,7 @@ POST VNF Configuration - Method not implemented
... Test title: POST VNF Configuration - Method not implemented
... Test objective: The objective is to test that POST method is not allowed to create a new VNF configuration
... Pre-conditions: A VNF instance is instantiated. The VNF instance is alrseady configured
... Reference: clause 9.4.2.3.1 - ETSI GS NFV-SOL 002 [2] v2.4.1
... Reference: Clause 9.4.2.3.1 - ETSI GS NFV-SOL 002 [2] v2.6.1
... Config ID: Config_prod_VE
... Applicability: none
... Post-Conditions: none
......@@ -83,7 +83,7 @@ PUT VNF Configuration - Method not implemented
... Test title: PUT VNF Configuration - Method not implemented
... Test objective: The objective is to test that PUT method is not allowed to modify an existing VNF configuration
... Pre-conditions: A VNF instance is instantiated. The VNF instance is already configured
... Reference: clause 9.4.2.3.3 - ETSI GS NFV-SOL 002 [2] v2.4.1
... Reference: Clause 9.4.2.3.3 - ETSI GS NFV-SOL 002 [2] v2.6.1
... Config ID: Config_prod_VE
... Applicability: none
... Post-Conditions: none
......@@ -95,7 +95,7 @@ DELETE VNF Configuration - Method not implemented
... Test title: Delete VNF Configuration - Method not implemented
... Test objective: The objective is to test that DELETE method is not allowed to delete an existing VNF configuration
... Pre-conditions: A VNF instance is instantiated. The VNF instance is already configured
... Reference: clause 9.4.2.3.5 - ETSI GS NFV-SOL 002 [2] v2.4.1
... Reference: Clause 9.4.2.3.5 - ETSI GS NFV-SOL 002 [2] v2.6.1
... Config ID: Config_prod_VE
... Applicability: none
... Post-Conditions: The VNF configuration is not deleted by the unsuccessful operation
......@@ -126,8 +126,7 @@ Send VNF configuration
Check HTTP Response Status Code Is
[Arguments] ${expected_status}
${status}= Convert To Integer ${expected_status}
Should Be Equal As Strings ${response['status']} ${status}
Should Be Equal As Strings ${response['status']} ${expected_status}
Log Status code validated
Check HTTP Response Header Contains
......
SOL002/VNFConfiguration-API/SOL002-VNFConfiguration-API.json deleted 100644 → 0
View file @ 3668ac55
{
"swagger": "2.0",
"info": {
"version": "1.1.1",
"title": "SOL002 - VNF Configuration interface",
"description": "VNF Configuration interface of ETSI NFV SOL002\n\nIMPORTANT: Please note that this file might be not aligned to the current version of the ETSI Group Specification it refers to. In case of discrepancies the published ETSI Group Specification takes precedence.\n\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 002 V2.4.1",
"url": "http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/02.04.01_60/gs_NFV-SOL002v020401p.pdf"
},
"basePath": "/vnfconfig/v1",
"schemes": [
"http",
"https"
],
"consumes": [
"application/json"
],
"produces": [
"application/json"
],
"paths": {
"/configuration": {
"get": {
"summary": "Read VNF/VNFC configuration from VNF.",
"description": "The client can use this method to read configuration information about a VNF instance and/or its VNFC instances.\n",
"responses": {
"200": {
"description": "OK\nConfiguration information about a VNF instance was read successfully. The response body shall contain a representation of the configuration resource.\n",
"schema": {
"$ref": "#/definitions/VnfConfiguration"
}
},
"400": {
"description": "Bad Request\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or a syntactically incorrect payload body), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\n ---\n\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.\n ---\n\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.\n",
"headers": {
"Content-Type": {
"description": "The MIME type of the body of the response.",
"type": "string",
"maximum": 1,
"minimum": 1
},
"WWW-Authenticate": {
"description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n",
"type": "string",
"maximum": 1,
"minimum": 0
}
},
"schema": {
"description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
"type": "object",
"required": [
"status",
"detail"
],
"properties": {
"type": {
"description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
"type": "string",
"format": "URI"
},
"title": {
"description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
"type": "string"
},
"status": {
"description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
"type": "integer"
},
"detail": {
"description": "A human-readable explanation specific to this occurrence of the problem.\n",
"type": "string"
},
"instance": {
"description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
"type": "string",
"format": "URI"
}
}
}
},
"401": {
"description": "Unauthorized\nIf the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n",
"headers": {
"Content-Type": {
"description": "The MIME type of the body of the response.",
"type": "string",
"maximum": 1,
"minimum": 1
},
"WWW-Authenticate": {
"description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n",
"type": "string",
"maximum": 1,
"minimum": 0
}
},
"schema": {
"description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
"type": "object",
"required": [
"status",
"detail"
],
"properties": {
"type": {
"description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
"type": "string",
"format": "URI"
},
"title": {
"description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
"type": "string"
},
"status": {
"description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
"type": "integer"
},
"detail": {
"description": "A human-readable explanation specific to this occurrence of the problem.\n",
"type": "string"
},
"instance": {
"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": "Forbidden\nIf the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided. It should include in the \"detail\" attribute information about the source of the problem, and may indicate how to solve it.\n",
"headers": {
"Content-Type": {
"description": "The MIME type of the body of the response.",
"type": "string",
"maximum": 1,
"minimum": 1
}
},
"schema": {
"description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
"type": "object",
"required": [
"status",
"detail"
],
"properties": {
"type": {
"description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
"type": "string",
"format": "URI"
},
"title": {
"description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
"type": "string"
},
"status": {
"description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
"type": "integer"
},
"detail": {
"description": "A human-readable explanation specific to this occurrence of the problem.\n",
"type": "string"
},
"instance": {
"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": "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.\n",
"headers": {
"Content-Type": {
"description": "The MIME type of the body of the response.",
"type": "string",
"maximum": 1,
"minimum": 1
}
},
"schema": {
"description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
"type": "object",
"required": [
"status",
"detail"
],
"properties": {
"type": {
"description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
"type": "string",
"format": "URI"
},
"title": {
"description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
"type": "string"
},
"status": {
"description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
"type": "integer"
},
"detail": {
"description": "A human-readable explanation specific to this occurrence of the problem.\n",
"type": "string"
},
"instance": {
"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": "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 in that case.\n",
"headers": {
"Content-Type": {
"description": "The MIME type of the body of the response.",
"type": "string",
"maximum": 1,
"minimum": 1
}
},
"schema": {
"description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
"type": "object",
"required": [
"status",
"detail"
],
"properties": {
"type": {
"description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
"type": "string",
"format": "URI"
},
"title": {
"description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
"type": "string"
},
"status": {
"description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
"type": "integer"
},
"detail": {
"description": "A human-readable explanation specific to this occurrence of the problem.\n",
"type": "string"
},