[MUSIC] What we've seen by our attempt to map the video service onto HTTP, is that a protocol like HTTP can have other protocols layered on top of it. In our case, we're layering a protocol for interacting with our video service, on top of the HTTP protocol, and this is one of the important principles to understand with, you know, network communication product protocols, is that you can layer them on top of each other. So, often you'll have a protocol like HTTP. And it may be layered on top of something else like TCP/IP which again may be layered on a series of other things. And then above HTTP may be other protocols that we create like the protocol for interacting with our video service. So we're specifying rules for interaction and exchange of messages and formatting of those messages, and where layering them on top of HTTP. And similarly, if we defined a nice interface, other protocols could even be layered on top of our protocol. So it's important to understand that HTTP, although it is what we're primarily targeting, is just a protocol layer among many in the application. And we have to understand the underlying protocol layers that are involved when we're building our application. But particularly, we want to understand what the different options are for building on top of HTTP. As we've seen, there are a lot of design choices that we're making about how we use the interface and constructs provided by HTTP to encode the data about our videos and send them to the service that we're talking to. Similarly, there's all kinds of design decisions such as how we design the URLs, how would we encode parameters, do we use it in a, a query parameter or a request body? Do we send request bodies that are multi-part encoded or form URL encoded? And there's all of these decisions that we have to make in the design of our application. And we do them by building layers of protocols in. Now an important, thing to know, of some of the common names for protocols that are built on top of HTTP, or some of the common design methodologies, that are built on top of HTTP, that describe, how you take messages or services and describe them using HTTP-based interactions. One that you may have heard of that gets built on top of HTTP is web services. And as anything that becomes very popular at some point. And is very technical. At some point, it gets taken and it's original true definition becomes watered down. So originally web services had a very specific definition. It meant that we were doing things like, describing our services with things like WSDL or Web Services Definition Language. Or sending messages that were based on SOAP, or simple object access protocol. But later on, what's happened over time is as sales and marketing and other folks start talking about web services which is inherently technical. They start talking about it in a more watered-down fashion. Web services, over time evolved from meaning that you were using WSDL and SOAP to just meaning that you had a service that was accessible over HTTP. Similarly, the really popular thing that you hear these days is about REST. And a REST API is a representational state transfer API. And this was something that was laid out by Ray, Roy Fielding in his di, PhD dissertation, and it's a very specific set of rules for building a protocol and interface on top of HTTP. Most, of the, the people that you say that have a REST API aren't actually doing what's described in full in the REST vision that Roy Fielding laid out in his dissertation. What they're doing is building a service that can be interacted with over HTTP and has REST-like properties potentially. So it maybe doing some of the things that REST describes but not all of them or not doing any of them at all. Everybody has started taking things that were inherently technical, web services or REST and they start describing them in a very loose manner. So when you hear web services, the true definition is something like WSDL and SOAP and other things being used. The true definition of REST is something very specific laid out in a PhD dissertation, but they get used very loosely. So someone says to you, do you have a REST API? You need to figure out do they mean, do you have the watered down definition of REST API, which means do you have some service that you can talk to over HTTP. Or do they really, specifically mean do you follow all of the rules of REST, all of the design principles of REST? And the answer is probably no. That's not what they mean. But it's important to understand that web services and REST are basically methodologies for building on top of HTTP, that describe very specific formats and principles that you use when you're building things on HTTP. But, what we're going to focus on, and we will be building things that are REST like, but are not true REST necessarily. Well, some of the things will be true REST. They're provided by the Spring framework that we're going to talk about. But most of the things we're going to be talking about really fall into, it is a service that is. I, you know, accessible via HTTP, and it may have REST-like properties or it may have web service-like properties, depending on how you design it, but this is the core of where things sit. This is where cloud services really come into play, is we're building in some object which can live in the cloud or some service which can live in the cloud and can receive information and be interacted with over HTTP. And depending on the design of that service, those interactions may follow a REST model, or they may follow a web service model. And it just depends on how they're actually implemented.
