REST and HTML - REST Tutorial

- [Instructor] Now that we've modeled and validated our API, we need to get familiar with the medium that we're actually using, HTTP. HTTP is great in that it underlies the entire web. It's well-documented and understood by clients and all the tools out there and is the usual foundation of a REST API. Unfortunately, this leads to the first misunderstanding that's worth explaining. HTTP is a protocol. XML is a markup language. JSON is a notation. There are XML standards that can add structure and meaning to it. And there are JSON specifications that can add context and descriptions to that. Unfortunately, REST is none of the above. It's not a standard. It's not a specification and it's not a protocol. In fact, there are all kinds of debates about what is RESTful, RESTish, all the variations of that. While there are specifications for things like URLs and XML and JSON and HTTP, there are very few formal requirements for REST itself. There are lots of preferences and even more opinions. We'll talk about those later, but for the purpose of this session, but remember, that REST is a generally agreed upon set of principles or constraints. If for better understanding, I use a simple analogy. SOAP, or the previous way of designing APIs, is a lot like getting a mortgage. There's a very fixed process. It's a very detailed process with numerous instructions throughout. There's a ton of documentation upfront to tell you about every step of the process. There's detailed scenarios. If this happens, then do that. And there's complex error handling. If something doesn't happen the right way, there's a detailed process for resolving that as quickly and easily as possible. As an alternative, REST is like borrowing money from a friend for lunch. There's very few requirements. They have to have enough trust that you're going to compensate them, that you're going to return that in some way. There's no documentation at the beginning. As you learn more about the interaction, you learn how to improve it next time around. Most importantly, it's flexible based on the needs of both you and the other party. This flexibility is great. It gives you the opportunity to maybe buy them lunch tomorrow, to return the money, to give them a gift. There's a variety of different options. Unfortunately, this introduces ambiguity. This ambiguity has to be figured out and resolved, which brings us back to HTTP. HTTP is a well understood protocol that is both simple and powerful in its implementation. Every HTTP request and response has two parts. There are the headers and the payload. The payload is the HTML, the JSON, the XML, or whatever comes back that you can view, interact with and process. If it's just HTML, it's usually presented to the user on the screen.