Writing REST API error handling my way ?
Tags: api, rest, standards, json
Published: 2018-04-29 15:51:22

---
title: Writing REST API error handling my way ?
published: true
description: Writing REST API error handling my way ?
tags: api, rest, standards, json
---

Taking time to work more on my side project, I stumbled upon the usual issue on how to manage error handling globally on the API.

I usually would make my own structure and call it a day, but I thought it would be nice to review how other people are doing it (especially since I'm doing it in c#, a language I'm not proficient with).

So I started like everyone would with [{json:api}](http://jsonapi.org/).
Unfortunately for me there are two things that I don't like
1. Most of the c# libraries are focused on the response not on Creating/Updating/Deleting
2. The error handling [specs](http://jsonapi.org/format/#errors) and [examples](http://jsonapi.org/examples/#error-objects-multiple-errors) don't easily allow for 1:n field -> errors mapping. 

To expand on the second point more let's consider the situation of a registration page. 
```html
<form>
    <label>
        email
        <input type="text" name="username">
    </label>
    <label>
        password
        <input type="text" name="password">
    </label>
    <label>
        password confirm
        <input type="text" name="password_confirm">
    </label>
</form>
```

Using json api's spec the response, in case the username isn't long enough and it hits a _blacklist_ rule, would look like:

```json
{
  "errors": [
    {
      "source": { "pointer": "/data/attributes/username", "parameter": "username" },
      "title": "Username validation error",
      "detail": "Your username needs to be at least 6 characters."
    },
    {
      "source": { "pointer": "/data/attributes/username", "parameter": "username" },
      "title": "Username validation error",
      "detail": "Your username isn't valid."
    }
  ]
}

```
As you can see there's no direct way of knowing which field erred out without parsing the list. I would argue that _parameter_ usage in this case is slightly outside of the standard since it should be _a string indicating which URI query parameter caused the error_ .

Searching further, I've stumbled upon this [nice short list](https://nordicapis.com/best-practices-api-error-handling/) of how Google, Bing, Twitter, Facebook are handling the situation. Unfortunately for me, they're all returning an array of items, without any direct way of referencing the offending field.

Looking over [RFC 7807](https://tools.ietf.org/html/rfc7807#section-1) reveals a similar situation: 
```json
{
   "type": "https://example.net/validation-error",
   "title": "Your request parameters didn't validate.",
   "invalid-params": [ 
        {
            "name": "age",
            "reason": "must be a positive integer"
        },
        {
            "name": "color",
            "reason": "must be 'green', 'red' or 'blue'"
        }
   ]
}
```

I'm not going to go over [JSend](http://labs.omniti.com/labs/jsend) since it's a much simpler standard.

That being said, the way I envisioned having this was to just have the _errors_ as a collection of objects, not arrays, having the following structure: 
```json
{
  "errors": {
    "username": [
      {
        "source": { "pointer": "/data/attributes/username" },
        "title": "Username validation error",
        "detail": "Your username needs to be at least 6 characters."
      },
      {
        "source": { "pointer": "/data/attributes/username" },
        "title": "Username validation error",
        "detail": "Your username isn't valid."
      }
    ],
    "password": [
      {
        "source": { "pointer": "/data/attributes/password" },
        "title": "Password validation error",
        "detail": "Your username needs to be at least 6 characters."
      }
    ]
  }
}
```

How are you guys handling error responses ? 

Am I just lazy for not parsing the response to get to the form key or does anybody else know something that's obviously an issue with having the keys in the response ?