Skip to main content

Error Response

In the case of an error, Redfish REST API responds with an HTTP status code, as defined by the HTTP 1.1 specification and constrained by additional requirements defined in this specification.

The status codes alone often do not provide enough information to determine the error cause. The Redfish REST API returns extended error information as a JSON object with a single property named error.

Table 1. Error Code Response

Attribute

Description

Message ID

String indicating a specific error or message (not to be confused with the HTTP status code). This code can be used to access a detailed message of a message registry.

Message

This is the human-readable message, if provided. This property shall contain an optional human-readable message.

Message Args

An optional array of strings representing the substitution parameter values for the message. This shall be included in the Response: if a Message ID is specified for a parameterized message.

Severity

An optional string representing the severity of the error.

Resolution

An optional string describing recommended action(s) to take to resolve the error.

Related Properties

An optional array of JSON Pointers defining the specific properties within the JSON payload described by the message.

Note
While passing empty data in the request body of the POST call, the following error Message ID will be shown in the response.

  • POST Actions which require mandatory parameters for execution:

    "MessageId": "Base.1.5.ActionParameterMissing" or

    "MessageId": "Base.1.5.PropertyMissing" or

    "MessageId":"Base.1.5.EmptyJSON"

  • POST Action which is used for the creation of resources:

    "MessageId": "Base.1.5.ActionParameterMissing" or

    "MessageId": "Base.1.5.PropertyMissing" or

    "MessageId":"Base.1.5.EmptyJSON"

Table 2. Common error status codes
Error codeDescription

404 Not Found

The request specified a URI of a resource that does not exist. This status code is returned for any of the HTTP Methods namely GET, POST, PATCH, DELETE and PUT.

400 Bad Request

The request could not be processed because it contains missing or invalid information (such as validation error on an input field, a missing required value, and so on). An extended error shall be returned in the response body, as defined in the above-mentioned table. This is typically returned with a PATCH or POST response involving request parameters.

405 Method Not Found

The HTTP verb specified in the request (e.g., DELETE, GET, HEAD, POST, PUT, PATCH) is not supported for this request URI. The response shall include an Allow header which provides a list of methods that are supported by the resource identified by the Request-URI. This is typically returned with POST, PATCH, DELETE, and PUT on the URL for which it's not supported.

Request Validation Sequence​

  1. Check authorization. If not granted, throw 401 "Security.1.0. AccessDenied".

  2. Check entity privilege. If not granted, throw 403 "Security.1.0. InsufficientPrivilege".

  3. Check if URI exists or not. If it doesn’t exist, throw 404 “Base.1.0.ResourceMissingAtURI”

  4. Check whether Redfish is in firmware update. If Redfish is in firmware update, throw 403 "Security.1.0. FWUpdateInProgress".

  5. Check allow method. If operation not allowed, throw 405 " HttpStatus.1.0.MethodNotAllowed".

  6. Check request body media type. If not correct, throw 415 "HttpStatus.1.0.UnsupportedMediaType".

  7. Check request body format. If not correct, throw 400 "Base.1.0.UnrecognizedRequestBody".

  8. If the request method is PUT/PATCH check for the precondition header and if the header is not present, throw 428 "Ami.1.0.PreconditionHeaderMissing".

    If the header is available validate Precondition Header and throw 412 "HttpStatus.1.0.PreconditionFailed" if validation fails.

  9. Check for property validation errors in request-body and throw a suitable 400 BadRequest error.