Error Handling and Testing REST APIs

Transcript of the free preview lesson. Remaining lessons unlock with the full course.

Hello, my name is Josh Gardino, and in these lessons, I will show you how to handle errors and test REST APIs. Recall that HTTP response status codes are divided into several groups. Status codes in the 400 and 500 range are considered errors. However, the critical difference is that status codes beginning with a four are client errors and status codes beginning with a five are server errors. Client errors would be errors related to the request itself. The request might have contained improperly formatted JSON, access to the requested path was forbidden, the requested resource could not be found, and more. When client errors occur, it is important for the server to reply with the correct 400 series status code. However, maintaining the full details about the client error is not normally required on the server side. The client should be able to address the issue and send a new request. Of more concern on the server side are the server error codes, and these are the ones that begin with five. Although there are numerous server error response codes, by far, the most important and relevant one is 500. 500 indicates internal server error for an unexpected condition on the server side, which means that an error occurred. The 500 status code is intended to be a generic catchall response. However, it is typically the only type of server-side error code that REST API server-side code needs to handle. Other server-side error codes may be encountered by a client, such as 503 indicating that the server is not ready. But these types of responses are typically sent by an API gateway and not by the application itself. Let's take a look at the Department of Motor Vehicles API in Postman. Here is the v1/drivers GET endpoint and when I click Send, a 200 status code is returned and a list of all the drivers from the database. Now let's see how this looks in source code. Here is the handler for the GET method. It performs a select query on the database and returns all of the data. This works fine if no errors are encountered. However, let's force an error to occur. On line 12, I'm going to enter some invalid code. Let's restart the server and return to Postman. I will click send and as you can see, I did not receive a status code or any type of response. Postman is showing an ECONNRESET error. This means that the server did not respond with anything that Postman could process. Let's go back to where the server is running. My local server accurately caught the xyz error and displayed the full details to the console window. These details are called a stack trace and they're very important for debugging purposes. The first line in the error output tells me that this was a reference error because the server did not understand what xyz is, so the error's being captured properly but the client has no idea what happened. The server could be down, there could be a network issue on the client side, there could be a server-side error but the client has no way of knowing what transpired and that is because this code does not perform any type of error handling. When the error does occur, the server does detect that something went wrong but no response is sent because for the GET method, the only type of response that is sent is a 200. Now, let's add some error handling to the Node.js Express application with try and catch statements. Now the error is being handled and all errors will be caught on line 16. On line 17, I am sending a status of 500 to the client. Let's go back to Postman and try this out. Now, when I send the request, I do receive a response and it has a 500 status code indicating internal server error. The client does not know exactly what happened on the server side, but it has much more information than with the previous request. It is certainly possible to send the full details of the error back to the client, along with the 500 internal server error status code but this is certainly problematic. Most importantly, this exposes internal details about the API and this presents a potentially serious security issue but also, this information is not helpful for the client, so there is no reason to send it but that does not mean that the server has to return a generic server response message. Let's go back into the code and add a friendly error message. Now, when we send this request, we still receive a 500 but with a customized error message. Another reason to use a customized 500 status code message is to provide the client with a tracking or correlation ID that the staff on the client side of the API could share with the server-side staff in order to perform detailed troubleshooting. Thanks for watching. Stay tuned for the next lesson where I will show you how to use automated testing for GET requests in REST API.