[MUSIC] Both client and server can send bodies in the messages that they send through HTTP. So, for example, a client can include a body in the HTTP messages, a request that it sends to the server. And that body has some data in it that the server needs to use, to process the client's request. Similarly, the, the server can have data in the response that it sends back to the client, that the client needs in order to receive the results of its request. So, one of the really important issues that has to be sorted out in HTTP, is how do the client and server tell each other about what the data is and how to interpret the data that's being sent in those bodies of the HTTP messages? So, for example, you can imagine that you could have an image download service on a HTTP-based server. And depending on which image you access, it could have a different format. So, for example, the server could store images that are in JPEG format, as well as images that were in PNG format. And the resource identifier, the URL for that particular image, may not actually tell you what the format of the image is. It would be a good practice to encode the, the correct file extension into the resource, potentially, but it doesn't have to. So, when that message comes back from the server and has some image data in it, the client needs to be able to figure out, is this image data for a JPEG, is this image data for a PNG, or even if the server is sending back textual data to the client. It may need to tell the client how to interpret that textual data. For example, the server could send back pure, plain text to the client that the client is just supposed to display and not interpret in any special way. Or the server could send back HTML, which the client is expected to render as HTML and render all of the proper elements from HTML in a user interface, before showing it to the user. So in both cases, there's different types of data that are being sent back in the body and we need way of communicating how to interpret that data, what format the client or the server should interpret that data as being part of. Now, the way that this is done in HTTP is through what's called MIME types. And a MIME type is an identifier for a particular type or format of information. And the client and the server communicate to each other by passing MIME types back and forth, explaining how to interpret the bodies of the messages that they're sending. Now, if you go and look at the MIME types, you'll see a lot of common things that may seem familiar, expressed as MIME types. So, for example, you may see a MIME type that looks like image/jpg. And this would be the MIME type for a JPEG-encoded image. Similarly, the server could send back image/png, indicating this is a PNG image. Or, the server could send back text/plain to indicate this is just plain text or text/html. And all of these different MIME types are identifiers for a well known format for the data in the body of either a request or a response. And the client is supposed to look at these and the server is supposed to look at these MIME types, and then based on this, decide how to interpret the data. [BLANK_AUDIO] And again, all of this, these different MIME types, are typically describing. [BLANK_AUDIO] The body of the request. So, this body is being described by the MIME types. The format of that body is being described be the more the MIME types. And this allows a client and server to send back different types of data for a particular resource, or for a particular request, or for a particular response. And indicate to the other end of the conversation, how to interpret that data. Now you might say, shouldn't we just encode all of this into the URLs? But you can imagine that there may be particular resources on the server, for example, that we might want to map differently and have different formats for it and be able to change those formats in the servers. We don't want to couple our URL, necessarily, to the exact format that we are going to return the data in. So, having MIME types allows us to flexibly adapt our bodies and be able to tell the other end of the party, how we've decided to format those bodies. So, how do we communicate these MIME types that are associate with the bodies of requests and responses? This is where the headers in HTTP messages come into play. We need to provide meta information to either the client or the server, telling it how to interpret the body of the HTTP message. And, this meta information gets communicated as the content-type header in an HTTP message. And what the content-type header says, is this body of this message should be interpreted as a particular MIME type. So, the content type communicates the MIME type that's either a, that's associated with the body of either a request or a response. So, we can use the content-type header in both request messages, and response messages, that include a body. And so, either end of the conversation can look at the HTTP content-type header and then determine how the body should be interpreted. So, we learned about headers before and we saw that there were meta information that helped one end of the conversation to process, or handle, the message in some way. And in this case, this is a perfect example of how they're used. The content type is telling us the format of the body of a request, or of a response, and how the server, or the client, should interpret that data
