SOL003-VNFFaultManagementNotification-API.json

                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "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": "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 in that case.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "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": "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 withthis response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The 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": "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 [13] 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.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          }
        }
      },
      "get": {
        "description": "The GET method allows the server to test the notification endpoint that is provided by the client, e.g. during subscription.\n",
        "parameters": [
          {
            "name": "Authorization",
            "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
            "in": "header",
            "required": false,
            "type": "string"
          }
        ],
        "responses": {
          "204": {
            "description": "No Content\nThe notification endpoint was tested successfully. The response body shall be empty.\n",
            "headers": {
              "WWW-Authenticate": {
                "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n",
                "type": "string",
                "maximum": 1,
                "minimum": 0
              }
            }
          },
          "400": {
            "description": "Bad Request\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or a syntactically incorrect payload body), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\n ---\n\nIf the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n ---\n\nIf there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code.The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              },
              "WWW-Authenticate": {
                "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n",
                "type": "string",
                "maximum": 1,
                "minimum": 0
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "401": {
            "description": "Unauthorized\nIf the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              },
              "WWW-Authenticate": {
                "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n",
                "type": "string",
                "maximum": 1,
                "minimum": 0
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "403": {
            "description": "Forbidden\nIf the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided.  It should include in the \"detail\" attribute information about the source of the problem, and may indicate how to solve it.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "405": {
            "description": "Method Not Allowed\nIf a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted in that case.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "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": "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 in that case.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "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": "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 withthis response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The 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": "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 [13] 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.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          }
        }
      }
    }
  }
}