[MUSIC] So let's return to our example application for inserting video into a database and cataloging that information about the video. So that we can later go and retrieve these videos off the file system and the meta data that we've inserted for them. From this database of metadata. So, if we remember, we were sending commands to the application. And we were doing this from the command line. But what we like to do is have a mobile application that's somewhere else. That's not on the same host. And we'd like this application to be living, in the cloud. So we'd like all of this to live in the cloud somewhere. So how do we get, the, mobile device to send these commands which are received by the application and stored somewhere in the cloud? Well, now that we've learned about HTTP. We know one of the communication protocols that we could use to send these commands. So we can imagine that we are using HTTP to send the commands to the application. So, for example, we might want to use a PUT command to go and insert video into the application. So we might have PUT be the, the HTTP method that we're using when we're going to store a new video. Similarly, we might want to get a video that's already been previously posted. So we might send a GET command to query video or fetch the video. And then the application would receive that GET command. Go and process it. And send the results back to us. As an HTTP response. And we even have HTTP request that are being sent to carry out commands. Now, if we're going to send a request to put a video, we're probably going to need to include the data for that video with it. So for example, we could encode data for a video, inside a multi-part request. Or a multi-part body, to be more specific. A multi-part body that's included with an HTTP request. So we could, create a request that has this multi part v, body that includes the video and we'd go and store it. Similarly we might have inside that body, not only the video, but we might also have, the name, as a key value pair. So we have name, and then the actual name of the video. We might also want to tell them some extra, information, about that video to help process it. So we might want to do something like we could pr, print the content type. In a header. So that they would know information about the format, or encoding of the video, that we're sending to the server. So as we see, suddenly these HTTP constructs that we learned about have direct relationship on this application scenario that we've got where we're sending video to an application. But suddenly, rather than doing this on the command line, we are sending HTTP request to the video. And we're encoding parts of those request as multi-part bodies, or we could use URL encoded bodies, so for example if we're sending video it probably makes sense but if we're doing a simple GET query, it might make sense to send the query as parameters in the URL, so we have query param- params. So how do we identify particular videos? Well each video might have a URL. So that we can address that video, we know the host its stored on, and we know the path to that video on the server, so that it can go and access it some way. So the resource naming schemes are giving us the ability to go and address the resources that we're storing in this case. Similarly, on the response side, we need to know what happened with our commands? Did our commands work or not? So the HTTP response can have the HTTP response code. And so we can look and say, you know, is this a 200, did it find the video? Was it able to store the video? Or is this a error 500, did the server crash in some way? Or is this a 404? Did I request a video that doesnt' exist. So the response code can give us information about what's happening on the server when our commands are being sent to the application. Similarly the response can include the body, which will have the data. And this may be a video. Or this might be just text coming back that's, you know, a set of key value pairs or some other information in response to a query that we're issuing on the metadata. And again, we could tell the client what it's getting back, either the type of video or the how the key value pairs are encoded using the content type, [SOUND] header. So, suddenly we are getting the ability to express not only what we're sending the server but information about what we're sending back. So HTTP is giving us a framework to build an application where we are sending commands or messages to the service that's in the cloud and that's all we're going to term a service. It's just an application that we moved into the cloud that can receive these HTTP requests that carry commands and then provide the output back as HTTP responses and that's what we're going to call our cloud service. Is it's just applications, just like you've built before that maybe took parameters off the command line, but suddenly we're taking them from the internet using HTTP. And we're going to be focused on cloud services with HTTP because there's also other ways that you could communicate, but HTTP is by far and away, the most common method of communicating between mobile, mobile devices and cloud services. So, we've built this entire framework around the various constructs in HTTP that we can use to place our application in the cloud and then send it commands which we can read and process on the application side using these constructs that we understand, and then do something with the information. Now, one of the questions that arises is, there are lots of ways that we could express our command structure, our expectations about the formatting of those commands in HTTP. We can express the query parameters for requests that we're sending for information about the, the metadata that was stored with videos as query parameters or we could go and express that information as a multi-part set of parameters or URL encoded form parameters. We could store video with PUT request or we could decide that we want to store video with a POST request because we can also send a multi-part body along with a post request. We could use a delete HTTP method to tell the server to go and remove a video or we could just simply use a GET request to a specific URL to indicate to the application that we want to remove a video. So there's lots of things that we have to consider when we're trying to figure out how do we map our application onto HTTP. It, it give us a really, it gives us a really good structure for building these applications, but there's still lots of design decisions that we have regarding what are the structures that we use for our URLs? How do we express where video is on the server? because we could have arbitrary naming schemes. Which of the HTP request methods do we want to use for which actions? Do we allow doubling up of request methods? For example, we could have a GET and a POST, that both access the same query URL allowing us to send a query. So we can have one version that allows us to send a GET request with query parameters or we can have another version with a post request that sends URL encoded foam, form parameters. And both of them would get the job done. So we have to understand all of these areas where we can make design decisions and build on top of the HTTP protocol in order to build a very complex application
