Keen Sage
Keen Sage

Reputation: 1949

REST API: HTML generic error response for Invalid JSON

Service X host REST APIs and is behind service Y.

Clients -> Y -> X

For invalid JSON, service Y responds back with HTML error (shown below). Service X does not have control over Y.

<html>
<head><title>400 Bad Request</title></head>
<center><h1>400 Bad Request</h1></center>
</body>
</html>

For all other type of errors, X responds back with appropriate HTTP response code and an Error JSON (Following format).

{
    "errorCode": "InvalidXXX",
    "message": ""
}
  1. I am trying to check if there exists any RFC around REST API error response standards?
  2. Is there a security risk if service returns an error response with details mentioning the JSON is invalid?

I am trying to understand whether it will be fine for us to document this special case as part of integration guide for clients.

Upvotes: 0

Views: 1487

Answers (1)

cassiomolin
cassiomolin

Reputation: 130917

I am trying to check if there exists any RFC around REST API error response standards?

REST is an architectural style defined by Fielding in the chapter 5 of his dissertation and it says nothing about the response format for errors.

I assume you are doing REST over HTTP, so I advise you to choose the most suitable status code for each situation. Status codes are meant to indicate the result of the server's attempt to understand and satisfy the client's request.

Status codes are sometimes not sufficient to convey enough information about an error to be helpful and some details sent in the payload can help the client to understand what caused the error.

If you are looking for a standard from IETF to report errors, the closest you'll find is probably the RFC 7807. This specification defines simple JSON and XML document formats to report errors to the client, along with the application/problem+json and application/problem+xml media types.

Is there a security risk if service returns an error response with details mentioning the JSON is invalid?

When it's a client error, it makes sense to inform the client on what's wrong, so they can fix it and perform a new request. You shouldn't, however, leak any stack trace or internal details that could be exploited by a malicious user.

Upvotes: 2

Related Questions