How can you identify the source of a web API error?

2 HTTP status codes

Another way to identify the source of a web API error is to look at the HTTP status codes, which are numerical codes that indicate the outcome of each request and response. They are divided into five categories, based on the first digit: 1xx for informational, 2xx for success, 3xx for redirection, 4xx for client errors, and 5xx for server errors. The status codes can help you narrow down the cause of the error and suggest possible solutions. For example, if you see a 404 Not Found status code, it means that the web server could not find the resource you requested, so you may need to check if the URL is correct or if the resource exists. If you see a 401 Unauthorized or a 403 Forbidden status code, it means that you need to provide valid credentials or permissions to access the resource, so you may need to check your authentication or authorization methods. If you see a 500 Internal Server Error or a 503 Service Unavailable status code, it means that there is something wrong with the web server or the web API itself, so you may need to contact the web API provider or check their documentation.

3 Error messages

Besides the HTTP status codes, you can also look at the error messages that are returned by the web server or the web API in the response body or in the console. The error messages can provide more information about the nature and the location of the error, such as the parameter name, the line number, the function name, or the error code. The error messages can also vary depending on the format and the structure of the web API, such as JSON, XML, or GraphQL. For example, if you are using a JSON web API, you may see an error message like this:

{
  "error": {
    "code": "INVALID_REQUEST",
    "message": "The request is missing a required parameter: name"
  }
}        

This error message tells you that you need to include a name parameter in your request, otherwise the web API will reject it. If you are using a GraphQL web API, you may see an error message like this:

{
  "errors": [
    {
      "message": "Cannot query field 'age' on type 'User'",
      "locations": [
        {
          "line": 3,
          "column": 5
        }
      ]
    }
  ]
}        

This error message tells you that you are trying to query a field that does not exist in the User type, so you need to check your schema or your query.

4 Third-party tools

In addition to the browser's developer tools, the HTTP status codes, and the error messages, you can also use some third-party tools that can help you identify and fix web API errors. These tools can offer more features and functionalities than the browser's developer tools, such as testing, debugging, monitoring, or documenting web APIs. Some examples of these tools are Postman, Insomnia, Fiddler, or Swagger. These tools can help you create, send, and analyze web API requests and responses, as well as simulate different scenarios and conditions that may cause errors. For example, you can use Postman to create collections of web API requests and run them in different environments, such as development, testing, or production. You can also use Postman to write tests and assertions for your web API responses and check if they meet your expectations or specifications. You can also use Postman to generate documentation and reports for your web API collections and share them with others.

5 Here’s what else to consider

This is a space to share examples, stories, or insights that don’t fit into any of the previous sections. What else would you like to add?