CODEWITHSUNDEEP
resthttp
tsg
tsg

Reputation: 485

REST API verbose level of 4xx/5xx responses

I'm curious what is the most common way to serve 4xx/5xx error responses.

Usually I'm trying for places where it makes sense to put explicit error response which may looks like:

// 400 bad request
{
  "errorCode": 100,
  "message": "user-friendly message with info what happened"
}

From my point of view this will increase the speed of implementation of API, since you won't need to look into docs, send emails and so on :) The API will guide you and tell what's wrong.

But friend of mine told me that he's usually returns empty body, some http status code (400, 404, etc) and "RequestID" in header (for debug purposes). So he's typical error response looks like:

// 400 bad request
// Header: CorrelationID=123abc
(empty response body)

I've also investigate this question little bit and found a nice article about "Best Practices for REST API Error Handling". There I found that there is even a standard for REST API error handling - RFC 7807.

Based on this I have couple of questions:

  1. Do you use an RFC 7807 for your error responses?
  2. How verbose is your error response?

Upvotes: 0

Views: 366

Answers (1)

Evert
Evert

Reputation: 99571

We use application/problem+json extensively, and it's lovely. Our basic error will usually just have a message and a type, but where it can be useful for a developer we add more information.

It's nice to include a link to include more information about an error, and when it's a validation error we typically include information about which field failed.

Generally I would say: more is better. If a user of your API has a ton of information to go on to resolve their error, that's an excellent developer experience.

Your friend is not doing 'the wrong thing', but maybe not the best possible thing.

Upvotes: 2

Related Questions