{"openapi":"3.0.2","info":{"title":"SOL002 - VNF LCM Coordination interface","description":"SOL002 - VNF Lifecycle Coordination Interface IMPORTANT: Please note that this file might be not aligned to the current\nversion of the ETSI Group Specification it refers to and has not been approved by the ETSI NFV ISG. In case of\ndiscrepancies the published ETSI Group Specification takes precedence.\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":"1.2.0-impl:etsi.org:ETSI_NFV_OpenAPI:1"},"externalDocs":{"description":"ETSI GS NFV-SOL 002 V3.5.1","url":"https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/03.03.01_60/gs_NFV-SOL002v030301p.pdf"},"servers":[{"url":"http://127.0.0.1/lcmcoord/v1"},{"url":"https://127.0.0.1/lcmcoord/v1"}],"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":{"summary":"Retrieve API version information","description":"The GET method reads API version information. This method shall follow the provisions specified in table 4.6.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.\n","responses":{"200":{"description":"200 OK\nAPI version information was read successfully. The response body shall contain 4.4 API version information, as defined in clause 4.4.1.13.\n","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 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"401":{"description":"401 UNAUTHORIZED\nIf the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"403":{"description":"403 FORBIDDEN\nIf the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided. It should include in the \"detail\" attribute information about the source of the problem, and may indicate how to solve it.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"404":{"description":"404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"405":{"description":"405 METHOD NOT ALLOWED\nIf a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"406":{"description":"406 NOT ACCEPTABLE\nIf the \"Accept\" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"413":{"description":"413 PAYLOAD TOO LARGE\nIf the payload body of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for closing the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"414":{"description":"414 URI TOO LONG\nIf the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"416":{"description":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"422":{"description":"422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nThis error response code is only applicable for methods that have a request body.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"500":{"description":"500 INTERNAL SERVER ERROR\nIf there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"503":{"description":"503 SERVICE UNAVAILABLE\nIf the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}},"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\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 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}},"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\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 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}},"patch":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response\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 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}},"delete":{"description":"This method is not supported. When this method is requested on this resource, the API producer shall return a \"405 Method Not Allowed\" response\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 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}}},"/coordinations":{"parameters":[{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"post":{"description":"This POST method requests the coordination of an LCM operation occurrence with\na management operation executed in the API producer.\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":"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/LcmCoordRequest"},"responses":{"201":{"$ref":"#/components/responses/Coordination.Post"},"202":{"$ref":"#/components/responses/Coordination_async.Post"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\nIf the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"401":{"description":"401 UNAUTHORIZED\nIf the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"403":{"description":"403 FORBIDDEN\nIf the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided. It should include in the \"detail\" attribute information about the source of the problem, and may indicate how to solve it.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"404":{"description":"404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"405":{"description":"405 METHOD NOT ALLOWED\nIf a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"406":{"description":"406 NOT ACCEPTABLE\nIf the \"Accept\" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"422":{"description":"422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nThis error response code is only applicable for methods that have a request body.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"500":{"description":"500 INTERNAL SERVER ERROR\nIf there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"503":{"description":"503 SERVICE UNAVAILABLE\nIf the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}}},"/coordinations/{coordinationId}":{"parameters":[{"$ref":"#/components/parameters/coordinationId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"get":{"description":"The GET method reads a coordination result.\n","responses":{"200":{"$ref":"#/components/responses/IndividualLcmCoord.Get"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\nIf the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"401":{"description":"401 UNAUTHORIZED\nIf the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"403":{"description":"403 FORBIDDEN\nIf the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided. It should include in the \"detail\" attribute information about the source of the problem, and may indicate how to solve it.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"404":{"description":"404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"405":{"description":"405 METHOD NOT ALLOWED\nIf a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"406":{"description":"406 NOT ACCEPTABLE\nIf the \"Accept\" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"416":{"description":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"422":{"description":"422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nThis error response code is only applicable for methods that have a request body.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"500":{"description":"500 INTERNAL SERVER ERROR\nIf there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"503":{"description":"503 SERVICE UNAVAILABLE\nIf the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}}},"/coordinations/{coordinationId}/cancel":{"parameters":[{"$ref":"#/components/parameters/coordinationId"},{"name":"Version","description":"Version of the API requested to use when responding to this request.\n","in":"header","required":true,"schema":{"type":"string"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235.\n","in":"header","required":false,"schema":{"type":"string"}}],"post":{"description":"The POST method initiates the cancellation of an ongoing coordination action.\n","responses":{"202":{"$ref":"#/components/responses/coordinationCancel.Post"},"400":{"description":"400 BAD REQUEST\n400 code can be returned in the following specified cases, the specific cause has to be proper specified in the \"ProblemDetails\" structure to be returned.\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nIf there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\nIf the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\nThe use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"401":{"description":"401 UNAUTHORIZED\nIf the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"403":{"description":"403 FORBIDDEN\nIf the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided. It should include in the \"detail\" attribute information about the source of the problem, and may indicate how to solve it.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"404":{"description":"404 NOT FOUND\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\nThis response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"405":{"description":"405 METHOD NOT ALLOWED\nIf a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"406":{"description":"406 NOT ACCEPTABLE\nIf the \"Accept\" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"409":{"description":"409 CONFLICT\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"416":{"description":"416 Range Not Satisfiable\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"422":{"description":"422 UNPROCESSABLE ENTITY\nIf the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\nThis error response code is only applicable for methods that have a request body.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"429":{"description":"429 TOO MANY REQUESTS\nIf the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition (\"rate limiting\"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the \"Retry-After\" HTTP header. The \"ProblemDetails\" structure shall be provided and shall include in the \"detail\" attribute more information about the source of the problem.\nThe period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"500":{"description":"500 INTERNAL SERVER ERROR\nIf there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"503":{"description":"503 SERVICE UNAVAILABLE\nIf the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"504":{"description":"504 GATEWAY TIMEOUT\nIf the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","schema":{"type":"string","maximum":1,"minimum":1}},"WWW-Authenticate":{"description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n","schema":{"type":"string","maximum":1,"minimum":0}},"Version":{"description":"Version of the API used in the response.\n","schema":{"type":"string","maximum":1,"minimum":1}}},"content":{"application/json":{"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}}}}}},"components":{"parameters":{"coordinationId":{"name":"coordinationId","in":"path","description":"Identifier of the LCM coordination. This identifier can be retrieved from the\nresource referenced by the \"Location\" HTTP header in the response to a\nPOST request to the \"Coordinations\" resource\n","required":true,"style":"simple","explode":false,"schema":{"type":"string"}}},"requestBodies":{"LcmCoordRequest":{"description":"Parameters for the coordination action as defined in clause 10.5.2.2.\n","content":{"application/json":{"schema":{"type":"object","required":["vnfInstanceId","vnfLcmOpOccId","lcmOperationType","coordinationActionName","_links"],"properties":{"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfLcmOpOccId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"lcmOperationType":{"description":"The enumeration LcmOperationForCoordType defines the permitted values to represent VNF lifecycle operation types in VNF LCM operation coordination actions. * INSTANTIATE: Represents the \"Instantiate VNF\" LCM operation. * SCALE: Represents the \"Scale VNF\" LCM operation. * SCALE_TO_LEVEL: Represents the \"Scale VNF to Level\" LCM operation. * CHANGE_FLAVOUR: Represents the \"Change VNF Flavour\" LCM operation. * TERMINATE: Represents the \"Terminate VNF\" LCM operation. * HEAL: Represents the \"Heal VNF\" LCM operation. * OPERATE: Represents the \"Operate VNF\" LCM operation. * CHANGE_EXT_CONN: Represents the \"Change external VNF connectivity\" LCM operation. * MODIFY_INFO: Represents the \"Modify VNF Information\" LCM operation. * CREATE_SNAPSHOT: Represents the \"Create VNF Snapshot\" LCM operation. * REVERT_TO_SNAPSHOT: Represents the \"Revert To VNF Snapshot\" LCM operation. * CHANGE_VNFPKG: Represents the \"Change current VNF package\" LCM operation.\n","type":"string","enum":["INSTANTIATE","SCALE","SCALE_TO_LEVEL","CHANGE_FLAVOUR","TERMINATE","HEAL","OPERATE","CHANGE_EXT_CONN","MODIFY_INFO","CREATE_SNAPSHOT","REVERT_TO_SNAPSHOT","CHANGE_VNFPKG"]},"coordinationActionName":{"description":"An identifier that is unique within a VNF descriptor.\n","type":"string"},"inputParams":{"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"},"_links":{"description":"Links to resources related to this request.\n","type":"object","required":["vnfLcmOpOcc","vnfInstance"],"properties":{"vnfLcmOpOcc":{"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"}}},"vnfInstance":{"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"}}}}}}}}},"required":true}},"responses":{"Coordination.Post":{"description":"201 CREATED\nShall be returned when the API producer has chosen the synchronous mode,\nwhich may be chosen for coordination actions that finish within the time\nframe in which an HTTP response is expected.\nThe response body shall contain an LcmCoord data structure that represents\nthe result of the coordination action.\nThe HTTP response shall include a \"Location\" HTTP header that indicates the URI\nof the \"Individual coordination action\" resource that has been created as the\nresult of the finished coordination procedure.\n","headers":{"Version":{"description":"The used API version.\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"}},"Content-Type":{"description":"The MIME type of the body of the response.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"URI of the \"Individual coordination action\" resource\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}}},"content":{"application/json":{"schema":{"description":"This type represents an LCM coordination result.\n","type":"object","required":["id","coordinationResult","vnfInstanceId","vnfLcmOpOccId","lcmOperationType","coordinationActionName","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"coordinationResult":{"description":"The enumeration LcmCoordResultType defines the permitted values to represent the result of executing an LCM coordination action. The coordination result also implies the action to be performed by the VNFM as the follow-up to this coordination. Value | Description ------|------------ CONTINUE | The related LCM operation shall be continued, staying in the state \"PROCESSING\". ABORT | The related LCM operation shall be aborted by transitioning into the state \"FAILED_TEMP\". CANCELLED | The coordination action has been cancelled upon request of the API consumer, i.e. the VNFM. The related LCM operation shall be aborted by transitioning into the state \"FAILED_TEMP\".\n","type":"string","enum":["CONTINUE","ABORT","CANCELLED"]},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfLcmOpOccId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"lcmOperationType":{"description":"The enumeration LcmOperationForCoordType defines the permitted values to represent VNF lifecycle operation types in VNF LCM operation coordination actions. * INSTANTIATE: Represents the \"Instantiate VNF\" LCM operation. * SCALE: Represents the \"Scale VNF\" LCM operation. * SCALE_TO_LEVEL: Represents the \"Scale VNF to Level\" LCM operation. * CHANGE_FLAVOUR: Represents the \"Change VNF Flavour\" LCM operation. * TERMINATE: Represents the \"Terminate VNF\" LCM operation. * HEAL: Represents the \"Heal VNF\" LCM operation. * OPERATE: Represents the \"Operate VNF\" LCM operation. * CHANGE_EXT_CONN: Represents the \"Change external VNF connectivity\" LCM operation. * MODIFY_INFO: Represents the \"Modify VNF Information\" LCM operation. * CREATE_SNAPSHOT: Represents the \"Create VNF Snapshot\" LCM operation. * REVERT_TO_SNAPSHOT: Represents the \"Revert To VNF Snapshot\" LCM operation. * CHANGE_VNFPKG: Represents the \"Change current VNF package\" LCM operation.\n","type":"string","enum":["INSTANTIATE","SCALE","SCALE_TO_LEVEL","CHANGE_FLAVOUR","TERMINATE","HEAL","OPERATE","CHANGE_EXT_CONN","MODIFY_INFO","CREATE_SNAPSHOT","REVERT_TO_SNAPSHOT","CHANGE_VNFPKG"]},"coordinationActionName":{"description":"Indicates the actual LCM coordination action. The coordination actions that a VNF supports are declared in the VNFD.\n","type":"string"},"outputParams":{"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"},"warnings":{"description":"Warning messages that were generated while the operation was executing.\n","type":"string"},"error":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self","vnfLcmOpOcc","vnfInstance"],"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"}}},"vnfLcmOpOcc":{"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"}}},"vnfInstance":{"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"}}}}}}}}}},"Coordination_async.Post":{"description":"202 Accepted\nShall be returned when the API producer has chosen the asynchronous mode and the\nrequest has been accepted for processing.\nThe response body shall be empty.\nThe HTTP response shall include a \"Location\" HTTP header that indicates the URI of\nthe \"Individual coordination action\" resource that will be created once the\ncoordination operation has finished successfully.\n","headers":{"Version":{"description":"The used API version.\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"}},"Content-Type":{"description":"The MIME type of the body of the response.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"Used in redirection, or when a new resource has been created. This header field shall be present if the\nresponse status code is 201 or 3xx. In the present document this header field is also used if the response\nstatus code is 202 and a new resource was created.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}}},"content":{}},"IndividualLcmCoord.Get":{"description":"200 OK\nShall be returned when the coordination is finished and the coordination result has been read successfully.\nA representation of the \"Individual coordination action\" resource shall be returned in the response body.\n","headers":{"Version":{"description":"The used API version.","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"}},"Content-Type":{"description":"The MIME type of the body of the response.","style":"simple","explode":false,"schema":{"type":"string"}}},"content":{"application/json":{"schema":{"description":"This type represents an LCM coordination result.\n","type":"object","required":["id","coordinationResult","vnfInstanceId","vnfLcmOpOccId","lcmOperationType","coordinationActionName","_links"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"coordinationResult":{"description":"The enumeration LcmCoordResultType defines the permitted values to represent the result of executing an LCM coordination action. The coordination result also implies the action to be performed by the VNFM as the follow-up to this coordination. Value | Description ------|------------ CONTINUE | The related LCM operation shall be continued, staying in the state \"PROCESSING\". ABORT | The related LCM operation shall be aborted by transitioning into the state \"FAILED_TEMP\". CANCELLED | The coordination action has been cancelled upon request of the API consumer, i.e. the VNFM. The related LCM operation shall be aborted by transitioning into the state \"FAILED_TEMP\".\n","type":"string","enum":["CONTINUE","ABORT","CANCELLED"]},"vnfInstanceId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfLcmOpOccId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"lcmOperationType":{"description":"The enumeration LcmOperationForCoordType defines the permitted values to represent VNF lifecycle operation types in VNF LCM operation coordination actions. * INSTANTIATE: Represents the \"Instantiate VNF\" LCM operation. * SCALE: Represents the \"Scale VNF\" LCM operation. * SCALE_TO_LEVEL: Represents the \"Scale VNF to Level\" LCM operation. * CHANGE_FLAVOUR: Represents the \"Change VNF Flavour\" LCM operation. * TERMINATE: Represents the \"Terminate VNF\" LCM operation. * HEAL: Represents the \"Heal VNF\" LCM operation. * OPERATE: Represents the \"Operate VNF\" LCM operation. * CHANGE_EXT_CONN: Represents the \"Change external VNF connectivity\" LCM operation. * MODIFY_INFO: Represents the \"Modify VNF Information\" LCM operation. * CREATE_SNAPSHOT: Represents the \"Create VNF Snapshot\" LCM operation. * REVERT_TO_SNAPSHOT: Represents the \"Revert To VNF Snapshot\" LCM operation. * CHANGE_VNFPKG: Represents the \"Change current VNF package\" LCM operation.\n","type":"string","enum":["INSTANTIATE","SCALE","SCALE_TO_LEVEL","CHANGE_FLAVOUR","TERMINATE","HEAL","OPERATE","CHANGE_EXT_CONN","MODIFY_INFO","CREATE_SNAPSHOT","REVERT_TO_SNAPSHOT","CHANGE_VNFPKG"]},"coordinationActionName":{"description":"Indicates the actual LCM coordination action. The coordination actions that a VNF supports are declared in the VNFD.\n","type":"string"},"outputParams":{"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"},"warnings":{"description":"Warning messages that were generated while the operation was executing.\n","type":"string"},"error":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self","vnfLcmOpOcc","vnfInstance"],"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"}}},"vnfLcmOpOcc":{"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"}}},"vnfInstance":{"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"}}}}}}}}}},"coordinationCancel.Post":{"description":"202 Accepted\nShall be returned when the cancellation request has been accepted for processing.\nThe response shall have an empty payload body.\n","headers":{"Version":{"description":"The used API version.\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"}},"Content-Type":{"description":"The MIME type of the body of the response.\n","style":"simple","explode":false,"schema":{"type":"string"}},"Location":{"description":"Used in redirection, or when a new resource has been created. This header field shall be present if the\nresponse status code is 201 or 3xx. In the present document this header field is also used if the response\nstatus code is 202 and a new resource was created.\n","style":"simple","explode":false,"schema":{"type":"string","format":"url"}}},"content":{}}}}}