HTTP Responce Codes

When we're writing a mobile client or a web based client it's going to access resources on a server. One of the things that we need to understand is how to interpret the response codes that the server sends back to us. We have to know how to read what the server is telling us happened on the server from the numeric code. because this is a really important part of writing the logic in our client to appropriately react to what took place in the server.

We may need to re-send the request or re-try it, or we may need to go and look at our code because we see that there's an error in how we format it. So let's talk about how response codes are formatted and represented in the http protocol. So there's a series of response codes that are typically in the range of 100 to into the 500s. And the one XXX messages whence you will see for example. You might have 104, 105 anything in the hundred range is an informational message.

So the server's telling us something. The quest isn't completely processed yet. But it's giving us some information about your request. Now the next one that we care about are things that were successful. So request codes that start with two are successful request codes. So you asked for a resource, I found it, okay, I'm giving it to you. So one of the really important ones that we want to know from the two series is 200 which is okay. And this is basically the server telling you, you sent me a request, I found the resource, I took whatever action you wanted on that particular resource. It's okay, everything worked.

And the data that you're getting back in the body you can go and interpret it and you can assume that things were successful. This is a very important status code to know. Now, one thing to remember when you're building clients is you should remember the scheme that you used. I'm talking about 1XX, 2XX. It's important that when you're building your logic you be able to quickly differentiate between something that's successful verses something that's unsuccessful as I'll show in a second. 3XX is typically redirection. It means that, for example, something has moved. The client is going to have to do some extra work in order to completely send that request and get it processed.

So, for example, you know, you asked for a request. Are you sent a request on a resource that is now moved somewhere else. And so the server's going to tell you the new location of that resource and you are required to resend your request in order to have it processed and completed. So this is some type of redirection typically. Further work that the client's going to have to do in order to get its request completed. So it's not necessarily that the request was unsuccessful it was just that we have to do more. We're probably going to have to resend the request to a different location that the server's going to give us. That's typically what's happening with the three series.

The next series is 4XX. And what this is, is you messed up. The client messed up. So the server's going to tell you, that either the resource you requested doesn't exist. So for example 404 is a common error code that you're probably going to want to handle. And that's that the resource wasn't found or you may have, depending on if you're sending parameters to the data, you may have a response telling you that you've formatted your requests incorrectly.

So, for an example, in later parts of the course, we'll see when we're building in our web-based services and applications to handle data from the clients. We actually can enforce the rules that certain data is set from the request. And if data that we expect to be there is not, we can send back a response code to the client, telling it that its request was formatted improperly. 

And then the next series of response codes that we want to be aware of are the five series. And what these are are server errors. So this is something bad went wrong on the server. So a common one that you'll see is error 500 which is some error took place on the server you as the client need to know about because we didn't successfully complete your request and often the body of the message might tell you information about the error. So, for example, if you're building a or communication with a Java-based application, the application may return a stack trace to you in the body of the message telling you exactly what went wrong.

Although, you typically don't want to do that. You don't want to send to much information like a stack trace back in your response to a client because you don't want them to know that information. For security purposes you shouldn't be doing that. But it is helpful to have information about what went wrong to some degree. So when your building a client you want to build logic that reads these response codes and then takes the appropriate action.

So you want to handle the response differently based on the code. So you don't want to go and send a request and then blindly assume that it was correct, read the data out of the request and for example interpret that data as an image. You want to read the response code, see if you've gotten for example 200 okay. If you have you can go and interpret that data as an image. If you've gotten 5XX you shouldn't interpret that data as an image. You need to interpret as, you know, some information related to the error that, that server sent back to you. So you need to understand these response codes for you clients in order to put the right logic in them to evaluate the response that's coming back and determine if it was successfully completed or not.