Create an API error mapping

[Pantani]

Headline

Create an error mapping with message and codes for the API response

Why we need it?

• Easier 3trd-party integrations;
• Better error handling;
• Improve the documentation;

[ed255]

This will require coordination with the fronted team!

[Pantani]

@ed255 I mapped the most common errors. Can you check if it is missing something?

Code	Type	Message
1	ErrMissingParameter	Missing parameter: <_PARAMETER_NAME_>
2	ErrInvalidParameter	Invalid parameter: <_PARAMETER_NAME_>
3	ErrInvalidIdx	Invalid account index: <_IDX_>
4	ErrIdxNotFound	Account index not found in the state tree: <_IDX_>
5	ErrIdxMismatchEth	Account index is incompatible with hez eth address: <_IDX_>
6	ErrIdxMismatchBjj	Account index is incompatible with baby jubjub address: <_IDX_>
7	ErrIdxMismatchToken	Account index is incompatible with token id: <_IDX_>
8	ErrInvalidNonce	Invalid nonce: <_NONCE_>
9	ErrInvalidBjj	Invalid Baby JubJub address: <_ADDRESS_>
10	ErrBjjNotFound	Baby jubjub address not found: <_ADDRESS_>
11	ErrInvalidEth	Invalid hez ETH address: <_ADDRESS_>
12	ErrEthNotFound	Hez ETH address not found: <_ADDRESS_>
13	ErrInsufficientBalance	Insufficient balance: <_BALANCE_>
14	ErrInvalidSignature	Invalid signature
15	ErrInvalidType	Invalid tx type: <_TYPE_>
16	ErrFeeOverflow	The fee amount overflows 128 bits
17	ErrLowerFee	The fee is lower than the minimum coordinator fee in USD
18	ErrTxAlreadyExist	Transaction already exist into the pool
19	ErrTokenIdOverflow	The token id overflows 4-bit length
20	ErrClaimFails	Fail to claim withdrawal
21	ErrNotSynced	The node is node synced
22	ErrMalformedTx	Malformed transaction

Response example:

{
  "error": {
    "message": "Account index not found in the state tree: 277",
    "type": "ErrIdxNotFound",
    "code": 4
  }
}

[jeffprestes]

Great idea. However, along with the messages the standard HTTP error code, such as, 400 will still be returning, isn't it?

[Pantani]

100-level (Informational) — Server acknowledges a request
200-level (Success) — Server completed the request as expected
300-level (Redirection) — Client needs to perform further actions to complete the request
400-level (Client error) — Client sent an invalid request
500-level (Server error) — Server failed to fulfill a valid request due to an error with server

@jeffprestes, we can use the 400 lvl, because most of them were client errors, but others fit more for 500 lvls, we can send the generic API status code and define better code from the response, like the rfc7807, what do you think?

[jeffprestes]

As long as we stick with the appropriate HTTP status code it will look good to me. This way we will give a clear feedback to the API user and we will still REST protocol compliant.