GraphQL Error Handling

Error Handling Status Codes: Rest APIs vs GraphQL

HTTP response status codes represent the nature of the response when there is an API call to the server. These status codes are unique for the type of response the server sends.

For instance, if there is a successful API response, 200 OK is its status code. Errors codes like 400 for Bad Request, 404 for Not Found, 500 for Internal Server Error, 502 for Bad Gateway, and so on are common responses denoting a semantic meaning for end users.

Rest APIs use these exact codes to handle responses. So, if a server sends a Not Found response, Rest APIs will send a 404 code.

However, with GraphQL, the server responds only with the status code 200, even if the response body contains an error. And this can be a source of confusion.

You get a response with status code 200 OK (success code) in GraphQL, but there’s a 400 Bad Request error. You have to manually pinpoint the issue by searching through the exact response body, rather than relying on the status code sent by GraphQL.

How BetterBugs Handles GraphQL Errors?

BetterBugs parses through the erroneous response body while auto-attaching them to your bug report. That way, you know the exact semantic meaning of the server response whenever a server uses GraphQL.

For instance, if your application uses GraphQL and your server response has an error, you will still get a 200 OK status code for every API call. BetterBugs derives the exact status code with code logic and only then shows the error code to attach to your bug report.

When you capture issues with BetterBugs, you clearly see the error in your bug report with the exact response code like 400 series, 500 series, etc rather than 200 OK every time you have an error in the server response.

And that’s how BetterBugs excels in handling and capturing GraphQL errors.