[MUSIC] The anatomy of an HTTP response is a very critical component to know when we're building applications that are communicating via HTTP. So, one of the important things that we have to consider when we're sending messages to some remote server and asking it to, give us a resource or take some action on that resource, is what happened on the server. We can't directly be present on the server when it's accessing that resource to see if it successfully accessed it. Or if there was a problem or if something else interesting happened, for example, the resource has been moved and the server needs to tell us about that. So one of the really important and first components that's related to the anatomy of a response message in HTDP is what's called the Status Line. And the Status Line is composed of two things. It's composed of a response code, which is a numeric code that tells us what happened on the server. Did it successfully find the resource? Did it not find the resource? Did it encounter some other type of error? And that response code is really important because it's telling the client. Here is what happened on the server. You couldn't directly observe what happened, but I'm going to tell you what happened, so that you can take the appropriate action. And a part of that response code is the, the first component is numeric, it's a numeric response code. And the second part of the status line is a phrase or a textual description of the reason for this code, or the explanation of it. So, this is, you know, text that's being set back to elaborate the response code that was sent back. So, for example, if there's a, arbitrary error, it may say there was a server here. And so the response code and the reason phrase give us a hint as to what happened on the server, and allow the client to take the appropriate action. The second component of an HTTP response is a series of headers. So, just like we saw before with request, we can send meta information to the client when we're providing a response to help that client figure out how to interpret that data that we're sending to it how to interpret the response that we're sending to it. And usually a very important component of the headers is as we saw with mim types the content type of what we're sending back. And this is a really critical piece of information to the client because the client needs to know what are you giving me what is the format of it. And we would like to not hardcode necessarily and assume a particular format. In many cases we end up hardcoding and assuming a particular format, but it's better if we can sit, look at the content type and decide the format for the body of the message. And then finally, we get the body, in the response. And so this is the actual data, that, the server, is sending back to us, in, response, to our HTTP request, to, take some action on a resource. So the body may be the actual resource itself, so, maybe we wanted to get an HTML file, that's just HTML and textural format stored in the server and the server is gone and told us it successfully retrieved that file. It is a content type text/HTML and in the body is where we would find the actual data, the textural data. For that HTML or for example we set a request that was for image lets say jpeg image, the server would return a response code to us telling us that it successfully found that image. It will set the content type to image/jpeg. And then it would, in the body, place the binary data for that image, the jpeg encoding of that data and then we would go and pull it out of the body and interpret it as an image. So, the response is very similar in construction to the request. We have headers we have a body. But the very critical sort of difference is we have this concept of a status on the server, because we can't directly observe what's going on so the server needs to tell us what happened in response to our request. Did we make a mistake in the way that we formatted the request? Did we try to access some resource that the server doesn't know about. Did the server, you know, explode and have an error and tell us about it. All of these things are communicated back to us in the response so that our client can react appropriately.
