[MUSIC] So as we've seen, resources play a very important role in the HTTP specification. Every time we're sending a request to the server, we're asking it to take some action on some resource that we're interested in. So, obviously, a really important part of understanding how to write clients that operate on HTTP is understanding how we talk about resources to the server and how we identify the resources that we're interested in so that the server can locate them and then take that appropriate action. Now in HTTP, the way that resources are identified is with what's called a uniform resource locator or URL, which is what everybody should be familiar with. And what a URL consists of is the specification of the protocol, which in this case, is http://, a host or server that's going to be talked to. Potentially a port number that's preceded by a colon and that is, we're going to connect to a specific port on that host. And then a path, that we would like to access, representing that resource. So, in this case, this is telling us which server to go and talk to on the network. Which port of that server we want to deliver our HTTP messages to. So this is typically going to be the port that the web application container or web server, whatever the entity is that's providing the server side of the HTTP communications. This is going to be the port on this host that it's listing. And then finally you have the path to the resource that we are interested in on that particular host. So then when the host receives this, what it's really interested in is typically the component at the end; which is the path. It already knows where it is, it already knows its port, but it needs to know the path to the resource that you're looking for. One other interesting component of URL's that are very important in HTTP communication from mobile clients and other clients trying to communicate with web based applications is the concept of query parameters. So you may have seen some URL's that look something like this. And what this is, is at the end of this we have what are called query parameters. And what query parameters are, is they are additional information that can be attached to the end of the URL, that's passed along to the server in order to communicate information, additional information, about what particular aspect of that resource the client is interested in. And these query parameters take the form of, they must follow a question mark that is placed at the end of the core part of the URL. So right after the resource path, we have a question mark, which we see right here. And then we have a series of key value pairs, where in this case we have a key which is A and then we have the value which is B. And so these query parameters follow at the end of the path that's being specified. Now if we want to specify multiple query parameters, that's also possible too. In this case we only have a single key value pair. We have the key A equals B. We can also pass multiple parameters. So for example, if we had a question mark and then we had A equals B, we can then add an ampersand to the query path, I mean the query parameters. And then we can have a second set of key valued pairs. So, in this case we have the first key is key 1 which is A. Then, the second key which is key 2, which is C. And then we would have B as the first value for key 1. And D is the value for key 2. So using query parameters, we can pass essentially extra information about a specific aspect of a resource to the server. And we can pass as many of these as we want up to a limit. Now, we just keep separating these query parameters with ampersand in order to understand where the separations are between the keys and the values. There are a couple of important concepts that we need to know about, if were going to pass query parameters to the client. One of those things is we can't have certain special characters appear within our query parameter values and keys. So as you can imagine on the server side, the server needs to easily be able to parse these query parameters by looking for the equal signs and the ampersand signs as well as the question mark. And if we began inserting these special symbols into our query parameters, it'd be hard for the server to extract them out. So, by default there are a set of characters that we're allowed to have in our query parameters and a set of characters that we aren't allowed to have in our query parameters. And any of those characters that aren't allowed to be in our query parameters have to be actually encoded using a process that's called URL encoding. And the idea behind this is, if we want to pass a value that has characters that aren't allowed in the query parameter spec. What we can do is instead replace those characters, with what are called their URL encoded equivalence so that we can still represent them, and the server understands how we represent them. But when we actually go and look at the characters there itself, none of these symbols show up. They get replaced with other things that mean the same things. So if we have an equals sign within our value for a particular key pair, it will get replaced with the URL encoded equivalent of equal sign. Now, you could go and look up all of the specific ways that you URL encode different characters into a query parameter, but you don't need to. Almost every programming language that you're going to work with has libraries and functions available to you to automatically encode your query parameters into a properly URL encoded string. So you don't need to go and learn them, you just need to understand the concept that. If you pass specific things like the equal sign or the ampersand or the question mark or the slash or space inside of one of your keys or values, then you need to make sure that you're URL is URL encoded. And so other than that, you don't need to do anything. But you do need to understand the cases where if you put something into one of your query parameters, you need to URL encode it. Often, when we're writing clients, they're going to be sending data to the server or sending requests to the server, we want to go ahead and URL encode all of our URLs that are dynamically constructed with some type of data that we're taking in. Because there's a possibility that that data may not strictly adhere to the query parameter specification.
