{"openapi":"3.0.2","info":{"title":"SOL003 - VNF Performance Management interface","description":"SOL003 - VNF Performance Management interface\n\nIMPORTANT: Please note that this file might be not aligned to the current\nversion of the ETSI Group Specification it refers to. In case of\ndiscrepancies the published ETSI Group Specification takes precedence.\n\nPlease report bugs to https://forge.etsi.org/rep/nfv/SOL002-SOL003/issues\n","contact":{"name":"NFV-SOL WG"},"license":{"name":"ETSI Forge copyright notice","url":"https://forge.etsi.org/etsi-forge-copyright-notice.txt"},"version":"2.1.0-impl:etsi.org:ETSI_NFV_OpenAPI:1"},"externalDocs":{"description":"ETSI GS NFV-SOL 003 V3.6.1","url":"https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/03.06.01_60/gs_NFV-SOL003v030601p.pdf"},"servers":[{"url":"http://127.0.0.1/vnfpm/v2"},{"url":"https://127.0.0.1/vnfpm/v2"}],"paths":{"/api-versions":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"get":{"description":"The GET method reads API version information. This method shall follow the provisions specified in SOL013 table 9.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"API version information was read successfully. The response body shall contain API version information, as defined in clause 7.1.6.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"Version":{"description":"The used API version.","schema":{"type":"string","maximum":1,"minimum":1}}},"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"}}}}}}}}},"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}},"post":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}},"put":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response as defined in SOL013 clause 6.4.\n","responses":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}}},"/pm_jobs":{"parameters":[{"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":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"post":{"description":"The POST method creates a PM job. See clause 6.4.2.3.1.\n","parameters":[{"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":{"$ref":"#/components/requestBodies/CreatePmJobRequest"},"responses":{"201":{"$ref":"#/components/responses/PmJobs.Post.201"},"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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":{"$ref":"#/components/responses/PmJobs.Post.422"},"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}},"get":{"description":"The API consumer can use this method to retrieve information about PM jobs. See clause 6.4.2.3.2.\n","parameters":[{"$ref":"#/components/parameters/filter_pm_jobs"},{"name":"all_fields","description":"Include all complex attributes in the response. See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The VNFM shall support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"fields","description":"Complex attributes to be included into the response. See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The VNFM should support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"name":"exclude_fields","description":"Complex attributes to be excluded from the response. See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The VNFM should support this parameter.\n","in":"query","required":false,"schema":{"type":"string"}},{"$ref":"#/components/parameters/exclude_default_pm_jobs"},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by the VNFM if the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this resource.\n","in":"query","required":false,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/PmJobs.Get.200"},"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}}},"/pm_jobs/{pmJobId}":{"parameters":[{"$ref":"#/components/parameters/PmJobId"},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"get":{"description":"The API consumer can use this method for reading an individual PM job. See clause 6.4.3.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/IndividualPmJob.Get.200"},"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 allows to modify an \"Individual PM job\" resource. See clause 6.4.3.3.4.\n","responses":{"200":{"$ref":"#/components/responses/IndividualPmJob.Patch.200"},"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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":{"$ref":"#/components/responses/IndividualPmJob.Patch.412"},"422":{"$ref":"#/components/responses/IndividualPmJob.Patch.422"},"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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":"This method terminates an individual PM job. See clause 6.4.3.3.5.\n","responses":{"204":{"$ref":"#/components/responses/IndividualPmJob.Delete.200"},"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}}},"/pm_jobs/{pmJobId}/reports/{reportId}":{"parameters":[{"$ref":"#/components/parameters/PmJobId"},{"$ref":"#/components/parameters/ReportId"}],"get":{"description":"The API consumer can use this method for reading an individual performance report. See clause 6.4.4.3.2.\n","parameters":[{"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":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/IndividualPerformanceReport.Get.200"},"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}}},"/thresholds":{"parameters":[{"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":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"post":{"description":"The POST method can be used by the API consumer to create a threshold. See clause 6.4.5.3.1.\n","parameters":[{"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":{"$ref":"#/components/requestBodies/CreateThresholdRequest"},"responses":{"201":{"$ref":"#/components/responses/Thresholds.Post.201"},"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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":{"$ref":"#/components/responses/Thresholds.Post.422"},"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}},"get":{"description":"The API consumer can use this method to query information about thresholds. See clause 6.4.5.3.2.\n","parameters":[{"$ref":"#/components/parameters/filter_thresholds"},{"name":"nextpage_opaque_marker","description":"Marker to obtain the next page of a paged response. Shall be supported by the VNFM if the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013 [8] for this resource.\n","in":"query","required":false,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/Thresholds.Get.200"},"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}}},"/thresholds/{thresholdId}":{"parameters":[{"$ref":"#/components/parameters/ThresholdId"},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}}],"get":{"description":"The API consumer can use this method for reading an individual threshold. See clause 6.4.6.3.2.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231.\n","in":"header","required":true,"schema":{"type":"string"}}],"responses":{"200":{"$ref":"#/components/responses/IndividualThreshold.Get.200"},"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 allows to modify an \"Individual threshold\" resource. See clause 6.4.6.3.4.\n","responses":{"200":{"$ref":"#/components/responses/IndividualThreshold.Patch.200"},"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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":{"$ref":"#/components/responses/IndividualThreshold.Patch.412"},"422":{"$ref":"#/components/responses/IndividualThreshold.Patch.422"},"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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":"This method allows to delete a threshold. See clause 6.4.6.3.5.\n","responses":{"204":{"$ref":"#/components/responses/IndividualThreshold.Delete.200"},"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"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":{"filter_pm_jobs":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013 [8]. The VNFM shall support receiving this parameter as part of the URI query string. The NFVO may supply this parameter. All attribute names that appear in the PmJob and in data types referenced from it shall be supported by the VNFM in the filter expression.\n","in":"query","required":false,"schema":{"type":"string"}},"exclude_default_pm_jobs":{"name":"exclude_default","in":"query","description":"Indicates to exclude the following complex attributes from the response. See clause 5.3 of ETSI GS NFV-SOL 013 [8] for details. The VNFM shall support this parameter. The following attributes shall be excluded from the PmJob structure in the response body if this parameter is provided, or none of the parameters \"all_fields,\" \"fields\", \"exclude_fields\", \"exclude_default\" are provided:  - reports","required":false,"schema":{"type":"string"}},"filter_thresholds":{"name":"filter","description":"Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV-SOL 013 [8]. The VNFM shall support receiving this parameter as part of the URI query string. The NFVO may supply this parameter. All attribute names that appear in the Thresholds data type and in data types referenced from it shall be supported by the VNFM in the filter expression\n","in":"query","required":false,"schema":{"type":"string"}},"PmJobId":{"name":"pmJobId","in":"path","description":"Identifier of the PM job.\nThis identifier can be retrieved from the resource referenced by the\n\"Location\" HTTP header in the response to a POST request creating a\nnew \"Individual PM job\" resource. It can also be retrieved from the \"id\"\nattribute in the payload body of that response.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"ReportId":{"name":"reportId","in":"path","description":"Identifier of the performance report.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}},"ThresholdId":{"name":"thresholdId","in":"path","description":"Identifier of the threshold.\nThis identifier can be retrieved from the resource referenced by the\n\"Location\" HTTP header in the response to a POST request creating a\nnew \"Individual threshold\" resource. It can also be retrieved from the \"id\"\nattribute in the payload body of that response.\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}}},"requestBodies":{"CreatePmJobRequest":{"description":"The VNF creation parameters","content":{"application/json":{"schema":{"description":"This type represents a request to create a PM job.\n","type":"object","required":["objectType","objectInstanceIds","criteria","callbackUri"],"properties":{"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceIds":{"description":"Identifiers of the measured object instances for which performance information is requested to be collected.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"subObjectInstanceIds":{"description":"Identifiers of the sub-object instances of the measured object instance for which performance information is requested to be collected. May be present if a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027for the related measured object type. If this attribute is present, the cardinality of the \"objectInstanceIds\" attribute shall be 1. If this attribute is absent and a sub-object is defined in clause 6.2 of ETSI GS NFV IFA 027 for the related measured object type, measurements will be taken for all sub-object instances of the measured object instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"criteria":{"description":"This type represents collection criteria for PM jobs. It shall comply with the provisions defined in table 6.5.3.3-1.\nNOTE 1:\tAt the end of each reportingPeriod, the API producer will inform the API consumer about availability of the \n        performance data collected for each completed collection period during this reportingPeriod. \n        The reportingPeriod should be equal to or a multiple of the collectionPeriod. In the latter case, the performance \n        data for the collection periods within one reporting period are reported together.\nNOTE 2:\tIn particular when choosing short collection and reporting periods, the number of PM jobs that can be supported \n        depends on the capability of the producing entity.\n","type":"object","required":["collectionPeriod","reportingPeriod"],"properties":{"performanceMetric":{"description":"This defines the types of performance metrics for the specified object instances. Valid values are specified as \"Measurement Name\" values in clause 7.2 of ETSI GS NFV-IFA 027. At least one of the two attributes (performance metric or group) shall be present.\n","type":"array","items":{"type":"string"}},"performanceMetricGroup":{"description":"Group of performance metrics. A metric group is a pre-defined list of metrics, known to the API producer that it can decompose to individual metrics. Valid values are specified as \"Measurement Group\" values in clause 7.2 of ETSI GS NFV-IFA 027. At least one of the two attributes (performance metric or group) shall be present.\n","type":"array","items":{"type":"string"}},"collectionPeriod":{"description":"SSpecifies the periodicity at which the API producer will collect performance information.  The unit shall be seconds. See notes 1 and 2.\n","type":"integer","minimum":0,"maximum":1024},"reportingPeriod":{"description":"Specifies the periodicity at which the API producer will report to the API consumer  about performance information. The unit shall be seconds. See notes 1 and 2.\n","type":"integer","minimum":0,"maximum":1024},"reportingBoundary":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"authentication":{"description":"* NOTE: 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\n        subscriptions. The value of clientPassword should be generated by a random process\n","type":"object","required":["authType"],"properties":{"authType":{"description":"Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values: * BASIC: In every HTTP request to the notification endpoint, use  HTTP Basic authentication with the client credentials. \n* OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the  notification endpoint, use an OAuth 2.0 Bearer token, obtained\n  using the client credentials grant type.\n* TLS_CERT: Every HTTP request to the notification endpoint is sent  over a mutually authenticated TLS session, i.e. not only the\n  server is authenticated, but also the client is authenticated\n  during the TLS tunnel setup.\n","type":"array","items":{"type":"string","enum":["BASIC","OAUTH2_CLIENT_CREDENTIALS","TLS_CERT"]}},"paramsBasic":{"description":"Parameters for authentication/authorization using BASIC. Shall be present if authType is \"BASIC\" and the contained information has not been provisioned out of band. Shall be absent otherwise.\n","type":"object","properties":{"userName":{"description":"Username to be used in HTTP Basic authentication. Shall be present if it has not been provisioned out of band.\n","type":"string"},"password":{"description":"Password to be used in HTTP Basic authentication. Shall be present if it has not been provisioned out of band.\n","type":"string"}}},"paramsOauth2ClientCredentials":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS. Shall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band. Shall be absent otherwise.\n","type":"object","properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type.  Shall be present if it has not been provisioned out of band. See note.\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. See note.\n","type":"string"},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true},"CreateThresholdRequest":{"description":"Request parameters to create a threshold resource.","content":{"application/json":{"schema":{"description":"This type represents a request to create a threshold.\n","type":"object","required":["objectType","objectInstanceId","criteria","callbackUri"],"properties":{"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subObjectInstanceIds":{"description":"Identifiers of the sub-object instances of the measured object instance associated with this threshold. May be present if a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measured object type. If this attribute is absent and a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the measured object type, measurements will be taken for all sub-object instances of the measured object instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"criteria":{"description":"This type represents criteria that define a threshold. It shall comply with the provisions defined in table 6.5.3.4-1.\nNOTE 1:\tIn the present document, simple thresholds are defined. The definition of additional threshold types is left for \n        future specification.\nNOTE 2:\tThe hysteresis is defined to prevent storms of threshold crossing notifications. When processing a request to create \n        a threshold, implementations should enforce a suitable minimum value for this attribute (e.g. override the value or \n        reject the request). \n","type":"object","required":["performanceMetric","thresholdType"],"properties":{"performanceMetric":{"description":"Defines the performance metric associated with the threshold. Valid values are specified as \"Measurement Name\" values in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"thresholdType":{"description":"Type of threshold. This attribute determines which other attributes are present in the data structure.\nPermitted values: -\tSIMPLE: Single-valued static threshold. See note 1.\n","type":"string","enum":["SIMPLE"]},"simpleThresholdDetails":{"description":"Details of a simple threshold. Shall be present if thresholdType=\"SIMPLE\".\n","type":"object","required":["thresholdValue","hysteresis"],"properties":{"thresholdValue":{"description":"The threshold value. Shall be represented as a floating point number.\n","type":"number","format":"float"},"hysteresis":{"description":"The hysteresis of the threshold.  Shall be represented as a non-negative floating point number.\nA notification with crossing direction \"UP\" will be generated if the measured value reaches or exceeds  \"thresholdValue\" + \"hysteresis\". A notification with crossing direction \"DOWN\" will be generated if the  measured value reaches or undercuts \"thresholdValue\" - \"hysteresis\". See note 2.\n","type":"number","minimum":0,"maximum":1024,"format":"float"}}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"authentication":{"description":"* NOTE: 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\n        subscriptions. The value of clientPassword should be generated by a random process\n","type":"object","required":["authType"],"properties":{"authType":{"description":"Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values: * BASIC: In every HTTP request to the notification endpoint, use  HTTP Basic authentication with the client credentials. \n* OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the  notification endpoint, use an OAuth 2.0 Bearer token, obtained\n  using the client credentials grant type.\n* TLS_CERT: Every HTTP request to the notification endpoint is sent  over a mutually authenticated TLS session, i.e. not only the\n  server is authenticated, but also the client is authenticated\n  during the TLS tunnel setup.\n","type":"array","items":{"type":"string","enum":["BASIC","OAUTH2_CLIENT_CREDENTIALS","TLS_CERT"]}},"paramsBasic":{"description":"Parameters for authentication/authorization using BASIC. Shall be present if authType is \"BASIC\" and the contained information has not been provisioned out of band. Shall be absent otherwise.\n","type":"object","properties":{"userName":{"description":"Username to be used in HTTP Basic authentication. Shall be present if it has not been provisioned out of band.\n","type":"string"},"password":{"description":"Password to be used in HTTP Basic authentication. Shall be present if it has not been provisioned out of band.\n","type":"string"}}},"paramsOauth2ClientCredentials":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS. Shall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band. Shall be absent otherwise.\n","type":"object","properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type.  Shall be present if it has not been provisioned out of band. See note.\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. See note.\n","type":"string"},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}},"required":true}},"responses":{"PmJobs.Post.201":{"description":"201 CREATED\n\nShall be returned when the PM job has been created successfully.\nThe response body shall contain a representation of the created \"Individual PM job\" resource,\nas defined in clause 6.5.2.7.\nThe HTTP response shall include a \"Location\" HTTP header that points to the created\n\"Individual PM job\" resource.\n","headers":{"Location":{"description":"The resource URI of the created PM Job","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a PM job.\n","type":"object","required":["id","objectType","objectInstanceIds","criteria","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceIds":{"description":"Identifiers of the VNF instances for which performance information is collected.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"subObjectInstanceIds":{"description":"Identifiers of the sub-object instances of the measured object instance for which performance information is requested to be collected. May be present if a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measured object type. If this attribute is present, the cardinality of the \"objectInstanceIds\" attribute shall be 1. If this attribute is absent and a sub-object is defined in clause 6.2 of ETSI GS NFV IFA 027 for the related measured object type, measurements will be taken for all sub-object instances of the measured object instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"criteria":{"description":"This type represents collection criteria for PM jobs. It shall comply with the provisions defined in table 6.5.3.3-1.\nNOTE 1:\tAt the end of each reportingPeriod, the API producer will inform the API consumer about availability of the \n        performance data collected for each completed collection period during this reportingPeriod. \n        The reportingPeriod should be equal to or a multiple of the collectionPeriod. In the latter case, the performance \n        data for the collection periods within one reporting period are reported together.\nNOTE 2:\tIn particular when choosing short collection and reporting periods, the number of PM jobs that can be supported \n        depends on the capability of the producing entity.\n","type":"object","required":["collectionPeriod","reportingPeriod"],"properties":{"performanceMetric":{"description":"This defines the types of performance metrics for the specified object instances. Valid values are specified as \"Measurement Name\" values in clause 7.2 of ETSI GS NFV-IFA 027. At least one of the two attributes (performance metric or group) shall be present.\n","type":"array","items":{"type":"string"}},"performanceMetricGroup":{"description":"Group of performance metrics. A metric group is a pre-defined list of metrics, known to the API producer that it can decompose to individual metrics. Valid values are specified as \"Measurement Group\" values in clause 7.2 of ETSI GS NFV-IFA 027. At least one of the two attributes (performance metric or group) shall be present.\n","type":"array","items":{"type":"string"}},"collectionPeriod":{"description":"SSpecifies the periodicity at which the API producer will collect performance information.  The unit shall be seconds. See notes 1 and 2.\n","type":"integer","minimum":0,"maximum":1024},"reportingPeriod":{"description":"Specifies the periodicity at which the API producer will report to the API consumer  about performance information. The unit shall be seconds. See notes 1 and 2.\n","type":"integer","minimum":0,"maximum":1024},"reportingBoundary":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"reports":{"description":"Information about available reports collected by this PM job.\n","type":"object","required":["href","readyTime"],"properties":{"href":{"description":"The URI where the report can be obtained.\n","type":"string","format":"url"},"readyTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"expiryTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"fileSize":{"description":"The size of the report file in bytes, if known.\n","type":"integer","minimum":0,"maximum":1024}}},"_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"}}},"objects":{"description":"Links to resources representing the measure object instances for which performance information is collected. Shall be present if the measured object instance information is accessible as a resource.\n","type":"array","items":{"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"}}}}}}}}}}},"PmJobs.Post.422":{"description":"422 Unprocessable Entity\n\nShall be returned upon the following error: The\ncontent type of the payload body is supported and\nthe payload body of a request contains syntactically\ncorrect data but the data cannot be processed.\nThe general cause for this error and its handling is\nspecified in clause 6.4 of ETSI GS NFV-SOL 013 [8],\nincluding rules for the presence of the response\nbody.\nSpecifically in case of this resource, the response\ncode 422 shall also be returned if the VNFM has\ntested the Notification endpoint as described in\nclause 6.4.9.3.2 and the test has failed.\nIn this case, the \"detail\" attribute in the\n\"ProblemDetails\" structure sh\n","headers":{"Location":{"description":"The resource URI of the created PM Job","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"PmJobs.Get.200":{"description":"200 OK\n\nShall be returned when information about zero or more PM jobs has been queried successfully.\nThe response body shall contain in an array the representations of zero or more PM jobs,\nas defined in clause 6.5.2.7.\nIf the \"filter\" URI parameter or one of the \"all_fields\", \"fields\" (if supported), \"exclude_fields\"\n(if supported) or \"exclude_default\" URI parameters was supplied in the request, the data in the\nresponse body shall have been transformed according to the rules specified in clauses 5.2.2 and 5.3.2\nof ETSI GS NFV-SOL 013, respectively.\nIf the VNFM supports alternative 2 (paging) according to clause 5.4..2.1 of ETSI GS NFV-SOL 013\nfor this resource, inclusion of the Link HTTP header in this response shall follow the provisions\nin clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Used for paging in the present document, see clause 4.7.2.1.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents a PM job.\n","type":"object","required":["id","objectType","objectInstanceIds","criteria","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceIds":{"description":"Identifiers of the VNF instances for which performance information is collected.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"subObjectInstanceIds":{"description":"Identifiers of the sub-object instances of the measured object instance for which performance information is requested to be collected. May be present if a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measured object type. If this attribute is present, the cardinality of the \"objectInstanceIds\" attribute shall be 1. If this attribute is absent and a sub-object is defined in clause 6.2 of ETSI GS NFV IFA 027 for the related measured object type, measurements will be taken for all sub-object instances of the measured object instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"criteria":{"description":"This type represents collection criteria for PM jobs. It shall comply with the provisions defined in table 6.5.3.3-1.\nNOTE 1:\tAt the end of each reportingPeriod, the API producer will inform the API consumer about availability of the \n        performance data collected for each completed collection period during this reportingPeriod. \n        The reportingPeriod should be equal to or a multiple of the collectionPeriod. In the latter case, the performance \n        data for the collection periods within one reporting period are reported together.\nNOTE 2:\tIn particular when choosing short collection and reporting periods, the number of PM jobs that can be supported \n        depends on the capability of the producing entity.\n","type":"object","required":["collectionPeriod","reportingPeriod"],"properties":{"performanceMetric":{"description":"This defines the types of performance metrics for the specified object instances. Valid values are specified as \"Measurement Name\" values in clause 7.2 of ETSI GS NFV-IFA 027. At least one of the two attributes (performance metric or group) shall be present.\n","type":"array","items":{"type":"string"}},"performanceMetricGroup":{"description":"Group of performance metrics. A metric group is a pre-defined list of metrics, known to the API producer that it can decompose to individual metrics. Valid values are specified as \"Measurement Group\" values in clause 7.2 of ETSI GS NFV-IFA 027. At least one of the two attributes (performance metric or group) shall be present.\n","type":"array","items":{"type":"string"}},"collectionPeriod":{"description":"SSpecifies the periodicity at which the API producer will collect performance information.  The unit shall be seconds. See notes 1 and 2.\n","type":"integer","minimum":0,"maximum":1024},"reportingPeriod":{"description":"Specifies the periodicity at which the API producer will report to the API consumer  about performance information. The unit shall be seconds. See notes 1 and 2.\n","type":"integer","minimum":0,"maximum":1024},"reportingBoundary":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"reports":{"description":"Information about available reports collected by this PM job.\n","type":"object","required":["href","readyTime"],"properties":{"href":{"description":"The URI where the report can be obtained.\n","type":"string","format":"url"},"readyTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"expiryTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"fileSize":{"description":"The size of the report file in bytes, if known.\n","type":"integer","minimum":0,"maximum":1024}}},"_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"}}},"objects":{"description":"Links to resources representing the measure object instances for which performance information is collected. Shall be present if the measured object instance information is accessible as a resource.\n","type":"array","items":{"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"}}}}}}}}}}}},"IndividualPmJob.Get.200":{"description":"200 OK\n\nShall be returned when information about an individual PM job has been read successfully.\nThe response body shall contain a representation of the \"Individual PM job\" resource,\nas defined in clause 6.5.2.7.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a PM job.\n","type":"object","required":["id","objectType","objectInstanceIds","criteria","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceIds":{"description":"Identifiers of the VNF instances for which performance information is collected.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"subObjectInstanceIds":{"description":"Identifiers of the sub-object instances of the measured object instance for which performance information is requested to be collected. May be present if a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measured object type. If this attribute is present, the cardinality of the \"objectInstanceIds\" attribute shall be 1. If this attribute is absent and a sub-object is defined in clause 6.2 of ETSI GS NFV IFA 027 for the related measured object type, measurements will be taken for all sub-object instances of the measured object instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"criteria":{"description":"This type represents collection criteria for PM jobs. It shall comply with the provisions defined in table 6.5.3.3-1.\nNOTE 1:\tAt the end of each reportingPeriod, the API producer will inform the API consumer about availability of the \n        performance data collected for each completed collection period during this reportingPeriod. \n        The reportingPeriod should be equal to or a multiple of the collectionPeriod. In the latter case, the performance \n        data for the collection periods within one reporting period are reported together.\nNOTE 2:\tIn particular when choosing short collection and reporting periods, the number of PM jobs that can be supported \n        depends on the capability of the producing entity.\n","type":"object","required":["collectionPeriod","reportingPeriod"],"properties":{"performanceMetric":{"description":"This defines the types of performance metrics for the specified object instances. Valid values are specified as \"Measurement Name\" values in clause 7.2 of ETSI GS NFV-IFA 027. At least one of the two attributes (performance metric or group) shall be present.\n","type":"array","items":{"type":"string"}},"performanceMetricGroup":{"description":"Group of performance metrics. A metric group is a pre-defined list of metrics, known to the API producer that it can decompose to individual metrics. Valid values are specified as \"Measurement Group\" values in clause 7.2 of ETSI GS NFV-IFA 027. At least one of the two attributes (performance metric or group) shall be present.\n","type":"array","items":{"type":"string"}},"collectionPeriod":{"description":"SSpecifies the periodicity at which the API producer will collect performance information.  The unit shall be seconds. See notes 1 and 2.\n","type":"integer","minimum":0,"maximum":1024},"reportingPeriod":{"description":"Specifies the periodicity at which the API producer will report to the API consumer  about performance information. The unit shall be seconds. See notes 1 and 2.\n","type":"integer","minimum":0,"maximum":1024},"reportingBoundary":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"reports":{"description":"Information about available reports collected by this PM job.\n","type":"object","required":["href","readyTime"],"properties":{"href":{"description":"The URI where the report can be obtained.\n","type":"string","format":"url"},"readyTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"expiryTime":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"fileSize":{"description":"The size of the report file in bytes, if known.\n","type":"integer","minimum":0,"maximum":1024}}},"_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"}}},"objects":{"description":"Links to resources representing the measure object instances for which performance information is collected. Shall be present if the measured object instance information is accessible as a resource.\n","type":"array","items":{"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"}}}}}}}}}}},"IndividualPmJob.Patch.200":{"description":"200 OK\n\nShall be returned when the request has been processed successfully.\nThe response body shall contain a data structure of type \"PmJobModifications\".\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents modifications to a PM job. It shall comply with the provisions defined in table 6.5.2.12-1.\nNOTE:\tAt least one of the attributes defined in this type shall be present in request bodies.\n","type":"object","oneOf":[{"required":["callbackUri"]},{"required":["authentication"]}],"properties":{"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"authentication":{"description":"* NOTE: 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\n        subscriptions. The value of clientPassword should be generated by a random process\n","type":"object","required":["authType"],"properties":{"authType":{"description":"Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values: * BASIC: In every HTTP request to the notification endpoint, use  HTTP Basic authentication with the client credentials. \n* OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the  notification endpoint, use an OAuth 2.0 Bearer token, obtained\n  using the client credentials grant type.\n* TLS_CERT: Every HTTP request to the notification endpoint is sent  over a mutually authenticated TLS session, i.e. not only the\n  server is authenticated, but also the client is authenticated\n  during the TLS tunnel setup.\n","type":"array","items":{"type":"string","enum":["BASIC","OAUTH2_CLIENT_CREDENTIALS","TLS_CERT"]}},"paramsBasic":{"description":"Parameters for authentication/authorization using BASIC. Shall be present if authType is \"BASIC\" and the contained information has not been provisioned out of band. Shall be absent otherwise.\n","type":"object","properties":{"userName":{"description":"Username to be used in HTTP Basic authentication. Shall be present if it has not been provisioned out of band.\n","type":"string"},"password":{"description":"Password to be used in HTTP Basic authentication. Shall be present if it has not been provisioned out of band.\n","type":"string"}}},"paramsOauth2ClientCredentials":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS. Shall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band. Shall be absent otherwise.\n","type":"object","properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type.  Shall be present if it has not been provisioned out of band. See note.\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. See note.\n","type":"string"},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"IndividualPmJob.Patch.412":{"description":"412 Precondition Failed\n\nShall be returned upon the following error: A\nprecondition given in an HTTP request header is not\nfulfilled.\nTypically, this is due to an ETag mismatch, indicating\nthat the resource was modified by another entity.\nThe response body should contain a ProblemDetails\nstructure, in which the \"detail\" attribute should convey\nmore information about the error.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualPmJob.Patch.422":{"description":"422 Unprocessable Entity\n\nShall be returned upon the following error: The\ncontent type of the payload body is supported and the\npayload body of a request contains syntactically\ncorrect data but the data cannot be processed.\nThe general cause for this error and its handling is\nspecified in clause 6.4 of ETSI GS NFV-SOL 013 [8],\nincluding rules for the presence of the response body.\nSpecifically in case of this resource, the response\ncode 422 shall also be returned if the VNFM has\ntested the Notification endpoint as described in\nclause 6.4.9.3.2 and the test has failed.\nIn this case, the \"detail\" attribute in the\n\"ProblemDetails\" structure shall convey more\ninformation about the error.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"IndividualPmJob.Delete.200":{"description":"204 NO CONTENT\n\nShall be returned when the PM job has been deleted successfully.\nThe 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\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualPerformanceReport.Get.200":{"description":"200 OK\n\nShall be returned when information of an individual performance report has been read successfully.\nThe response body shall contain a representation of the \"Individual performance report\" resource,\nas defined in clause 6.5.2.10.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type defines the format of a performance report provided by the VNFM to the NFVO as a result of collecting  performance information as part of a PM job. The type shall comply with the provisions defined in table 6.5.2.10-1.\nNOTE:\tThe sub-object allows to structure the measured object but is not to be confused with sub-counters which allow \n      to structure the measurement value.\n\nEXAMPLE:\n  Measured object: VnfInstanceXYZ\n  Sub-object: VnfcInstance1\n  Measurement: vCPU_utilization\n  Sub-counters: vCPU utilization of each of the vCPUs of VnfcInstance1 (vCPU utilization.vCPU1, vCPU_utilization.vCPU2, etc.).\n","type":"object","required":["entries"],"properties":{"entries":{"description":"List of performance information entries. Each performance report entry is for a given metric of a given object (i.e. VNF instance), but can include multiple collected values.\n","type":"array","items":{"type":"object","required":["objectType","objectInstanceId","performanceMetric","performanceValue"],"properties":{"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subObjectInstanceId":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"},"performanceMetric":{"description":"Name of the metric collected. This attribute shall contain the related \"Measurement Name\" value as defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"performanceValues":{"description":"List of performance values with associated timestamp.\n","type":"array","items":{"type":"object","required":["timeStamp","value"],"properties":{"timeStamp":{"description":"Date-time stamp. Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"value":{"description":"Value of the metric collected. The type of this attribute shall correspond to the related \"Measurement Unit\" as defined in clause 7.2. of ETSI GS NFV-IFA 027.\n","type":"object"},"context":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys (\"aString\", \"aNumber\", \"anArray\" and \"anObject\") is provided to illustrate that the values associated with different keys can be of different type.\n","type":"object"}}}}}}}}}}}},"Thresholds.Post.201":{"description":"201 CREATED\n\nShall be returned when a threshold has been created successfully.\nThe response body shall contain a representation of the created \"Individual threshold\" resource,\nas defined in clause 6.5.2.9.\nThe HTTP response shall include a \"Location\" HTTP header that contains the resource URI of the\ncreated threshold resource.\n","headers":{"Location":{"description":"TThe resource URI of the created VNF instance","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a threshold.\n","type":"object","required":["id","objectType","objectInstanceId","criteria","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subObjectInstanceIds":{"description":"Identifiers of the sub-object instances of the measured object instance associated with the threshold. May be present if a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measurement type. If this attribute is absent and a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measured object type, measurements will be taken for all sub-object instances of the measured object instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"criteria":{"description":"This type represents criteria that define a threshold. It shall comply with the provisions defined in table 6.5.3.4-1.\nNOTE 1:\tIn the present document, simple thresholds are defined. The definition of additional threshold types is left for \n        future specification.\nNOTE 2:\tThe hysteresis is defined to prevent storms of threshold crossing notifications. When processing a request to create \n        a threshold, implementations should enforce a suitable minimum value for this attribute (e.g. override the value or \n        reject the request). \n","type":"object","required":["performanceMetric","thresholdType"],"properties":{"performanceMetric":{"description":"Defines the performance metric associated with the threshold. Valid values are specified as \"Measurement Name\" values in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"thresholdType":{"description":"Type of threshold. This attribute determines which other attributes are present in the data structure.\nPermitted values: -\tSIMPLE: Single-valued static threshold. See note 1.\n","type":"string","enum":["SIMPLE"]},"simpleThresholdDetails":{"description":"Details of a simple threshold. Shall be present if thresholdType=\"SIMPLE\".\n","type":"object","required":["thresholdValue","hysteresis"],"properties":{"thresholdValue":{"description":"The threshold value. Shall be represented as a floating point number.\n","type":"number","format":"float"},"hysteresis":{"description":"The hysteresis of the threshold.  Shall be represented as a non-negative floating point number.\nA notification with crossing direction \"UP\" will be generated if the measured value reaches or exceeds  \"thresholdValue\" + \"hysteresis\". A notification with crossing direction \"DOWN\" will be generated if the  measured value reaches or undercuts \"thresholdValue\" - \"hysteresis\". See note 2.\n","type":"number","minimum":0,"maximum":1024,"format":"float"}}}}},"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"}}},"object":{"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"}}}}}}}}}},"Thresholds.Post.422":{"description":"422 Unprocessable Entity\n\nShall be returned upon the following error: The\ncontent type of the payload body is supported and\nthe payload body of a request contains\nsyntactically correct data but the data cannot be\nprocessed.\nThe general cause for this error and its handling is\nspecified in clause 6.4 of ETSI\nGS NFV-SOL 013 [8], including rules for the\npresence of the response body.\nSpecifically in case of this resource, the response\ncode 422 shall also be returned if the VNFM has\ntested the Notification endpoint as described in\nclause 6.4.9.3.2 and the test has failed.\nIn this case, the \"detail\" attribute in the\n\"ProblemDetails\" structure shall convey more\ninformation about the error\n","headers":{"Location":{"description":"TThe resource URI of the created VNF instance","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"Thresholds.Get.200":{"description":"200 OK\n\nShall be returned when information about zero or more thresholds has been queried successfully.\nIf the \"filter\" URI parameter was supplied in the request, the data in the response body shall have\nbeen transformed according to the rules specified in clause 5.2.2 of ETSI GS NFV-SOL 013.\nThe response body shall contain in an array the representations of zero or more thresholds,\nas defined in clause 6.5.2.9.\nIf the VNFM supports alternative 2 (paging) according to clause 5.4.2.1 of ETSI GS NFV-SOL 013\nfor this resource, inclusion of the Link HTTP header in this response shall follow the provisions\nin clause 5.4.2.3 of ETSI GS NFV-SOL 013.\n","headers":{"Location":{"description":"The resource URI of the created VNF instance","style":"simple","explode":false,"schema":{"type":"string","format":"url"}},"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}},"Link":{"description":"Reference to other resources. Used for paging in the present document, see clause 4.7.2.1.\n","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"type":"array","items":{"description":"This type represents a threshold.\n","type":"object","required":["id","objectType","objectInstanceId","criteria","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subObjectInstanceIds":{"description":"Identifiers of the sub-object instances of the measured object instance associated with the threshold. May be present if a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measurement type. If this attribute is absent and a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measured object type, measurements will be taken for all sub-object instances of the measured object instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"criteria":{"description":"This type represents criteria that define a threshold. It shall comply with the provisions defined in table 6.5.3.4-1.\nNOTE 1:\tIn the present document, simple thresholds are defined. The definition of additional threshold types is left for \n        future specification.\nNOTE 2:\tThe hysteresis is defined to prevent storms of threshold crossing notifications. When processing a request to create \n        a threshold, implementations should enforce a suitable minimum value for this attribute (e.g. override the value or \n        reject the request). \n","type":"object","required":["performanceMetric","thresholdType"],"properties":{"performanceMetric":{"description":"Defines the performance metric associated with the threshold. Valid values are specified as \"Measurement Name\" values in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"thresholdType":{"description":"Type of threshold. This attribute determines which other attributes are present in the data structure.\nPermitted values: -\tSIMPLE: Single-valued static threshold. See note 1.\n","type":"string","enum":["SIMPLE"]},"simpleThresholdDetails":{"description":"Details of a simple threshold. Shall be present if thresholdType=\"SIMPLE\".\n","type":"object","required":["thresholdValue","hysteresis"],"properties":{"thresholdValue":{"description":"The threshold value. Shall be represented as a floating point number.\n","type":"number","format":"float"},"hysteresis":{"description":"The hysteresis of the threshold.  Shall be represented as a non-negative floating point number.\nA notification with crossing direction \"UP\" will be generated if the measured value reaches or exceeds  \"thresholdValue\" + \"hysteresis\". A notification with crossing direction \"DOWN\" will be generated if the  measured value reaches or undercuts \"thresholdValue\" - \"hysteresis\". See note 2.\n","type":"number","minimum":0,"maximum":1024,"format":"float"}}}}},"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"}}},"object":{"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"}}}}}}}}}}},"IndividualThreshold.Get.200":{"description":"200 OK\n\nShall be returned when information about an individual threshold has been read successfully.\nThe response body shall contain a representation of the threshold, as defined in clause 6.5.2.9.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents a threshold.\n","type":"object","required":["id","objectType","objectInstanceId","criteria","callbackUri","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"objectType":{"description":"Type of the measured object. The applicable measured object type for a measurement is defined in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"objectInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"subObjectInstanceIds":{"description":"Identifiers of the sub-object instances of the measured object instance associated with the threshold. May be present if a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measurement type. If this attribute is absent and a sub-object is defined in clause 6.2 of ETSI GS NFV-IFA 027 for the related measured object type, measurements will be taken for all sub-object instances of the measured object instance.\n","type":"array","items":{"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n","type":"string"}},"criteria":{"description":"This type represents criteria that define a threshold. It shall comply with the provisions defined in table 6.5.3.4-1.\nNOTE 1:\tIn the present document, simple thresholds are defined. The definition of additional threshold types is left for \n        future specification.\nNOTE 2:\tThe hysteresis is defined to prevent storms of threshold crossing notifications. When processing a request to create \n        a threshold, implementations should enforce a suitable minimum value for this attribute (e.g. override the value or \n        reject the request). \n","type":"object","required":["performanceMetric","thresholdType"],"properties":{"performanceMetric":{"description":"Defines the performance metric associated with the threshold. Valid values are specified as \"Measurement Name\" values in clause 7.2 of ETSI GS NFV-IFA 027.\n","type":"string"},"thresholdType":{"description":"Type of threshold. This attribute determines which other attributes are present in the data structure.\nPermitted values: -\tSIMPLE: Single-valued static threshold. See note 1.\n","type":"string","enum":["SIMPLE"]},"simpleThresholdDetails":{"description":"Details of a simple threshold. Shall be present if thresholdType=\"SIMPLE\".\n","type":"object","required":["thresholdValue","hysteresis"],"properties":{"thresholdValue":{"description":"The threshold value. Shall be represented as a floating point number.\n","type":"number","format":"float"},"hysteresis":{"description":"The hysteresis of the threshold.  Shall be represented as a non-negative floating point number.\nA notification with crossing direction \"UP\" will be generated if the measured value reaches or exceeds  \"thresholdValue\" + \"hysteresis\". A notification with crossing direction \"DOWN\" will be generated if the  measured value reaches or undercuts \"thresholdValue\" - \"hysteresis\". See note 2.\n","type":"number","minimum":0,"maximum":1024,"format":"float"}}}}},"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"}}},"object":{"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"}}}}}}}}}},"IndividualThreshold.Patch.200":{"description":"200 OK\n\nShall be returned when the request has been processed successfully.\nThe response body shall contain a data structure of type \"ThresholdModifications\".\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents modifications to a threshold. It shall comply with the provisions defined in table 6.5.2.11-1.\nNOTE:\tAt least one of the attributes defined in this type shall be present in request bodies.\n","type":"object","oneOf":[{"required":["callbackUri"]},{"required":["authentication"]}],"properties":{"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"authentication":{"description":"* NOTE: 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\n        subscriptions. The value of clientPassword should be generated by a random process\n","type":"object","required":["authType"],"properties":{"authType":{"description":"Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values: * BASIC: In every HTTP request to the notification endpoint, use  HTTP Basic authentication with the client credentials. \n* OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the  notification endpoint, use an OAuth 2.0 Bearer token, obtained\n  using the client credentials grant type.\n* TLS_CERT: Every HTTP request to the notification endpoint is sent  over a mutually authenticated TLS session, i.e. not only the\n  server is authenticated, but also the client is authenticated\n  during the TLS tunnel setup.\n","type":"array","items":{"type":"string","enum":["BASIC","OAUTH2_CLIENT_CREDENTIALS","TLS_CERT"]}},"paramsBasic":{"description":"Parameters for authentication/authorization using BASIC. Shall be present if authType is \"BASIC\" and the contained information has not been provisioned out of band. Shall be absent otherwise.\n","type":"object","properties":{"userName":{"description":"Username to be used in HTTP Basic authentication. Shall be present if it has not been provisioned out of band.\n","type":"string"},"password":{"description":"Password to be used in HTTP Basic authentication. Shall be present if it has not been provisioned out of band.\n","type":"string"}}},"paramsOauth2ClientCredentials":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS. Shall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band. Shall be absent otherwise.\n","type":"object","properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type.  Shall be present if it has not been provisioned out of band. See note.\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. See note.\n","type":"string"},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}}}},"IndividualThreshold.Patch.412":{"description":"412 Precondition Failed\n\nShall be returned upon the following error: A\nprecondition given in an HTTP request header is\nnot fulfilled.\nTypically, this is due to an ETag mismatch,\nindicating that the resource was modified by\nanother entity.\nThe response body should contain a\nProblemDetails structure, in which the \"detail\"\nattribute should convey more information about the\nerror\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}},"IndividualThreshold.Patch.422":{"description":"422 Unprocessable entity\n\nShall be returned upon the following error: The\ncontent type of the payload body is supported and\nthe payload body of a request contains\nsyntactically correct data but the data cannot be\nprocessed.\nThe general cause for this error and its handling is\nspecified in clause 6.4 of ETSI\nGS NFV-SOL 013 [8], including rules for the\npresence of the response body.\nSpecifically in case of this resource, the response\ncode 422 shall also be returned if the VNFM has\ntested the Notification endpoint as described in\nclause 6.4.9.3.2 and the test has failed.\nIn this case, the \"detail\" attribute in the\n\"ProblemDetails\" structure shall convey more\ninformation about the error\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response. Reference: IETF RFC 7231\n","style":"simple","explode":false,"schema":{"type":"string"}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807.\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"IndividualThreshold.Delete.200":{"description":"204 NO CONTENT\n\nThe threshold was deleted successfully.\nThe 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\ncorresponding HTTP request has provided an invalid authorization token.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Version":{"description":"The used API version.","style":"simple","explode":false,"schema":{"type":"string"}}}}}}}