Introduction to RESTful APIs - Go Tutorial

- [Instructor] If you are a junior or mid-level engineer, you're in the right place to level up your skills if you're not familiar with this concept already, but if you are familiar, then please feel free to skip this video. Assuming you're still here, what exactly the RESTful API? Let's start with the basics. What really is even REST? RESTs or representational state transfer is a set of architectural principles for designing network applications. It's a standard really, and it's a standardized way for systems to communicate with one another over HTTP. Think of it as a language spoken between applications, enabling seamless data exchange. The REST is an IPC mechanism that almost always uses HTTP. A key concept in REST is the concept of the resource, which typically represents business objects such as a customer, or an entity, or something essentially that represent some business object or value. REST uses the HTTP verbs for manipulating resources which are accessed over a URL, or a uniform resource identifier. To quote Roy Fielding, who was a creator of REST, these are his his words. He says, "REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems." Now that's a mouthful. I understand, but stay with me and you'll realize this is all really very easy to understand. What are the component of a REST request? First, you have HTTP methods. The HTTP method here indicates the kind of operation that a client wants to perform on the resource. Common HTTP methods you're most likely are familiar with are the GET, the POST, the PUT, the PATCH, and the DELETE. When you access a webpage over the internet, you are making a GET request. And when you try and perform an action, you're trying to send data over, you are making a POST request. But more on that in a moment. You also have the Uniform Resource Identifier. You can think of this as the unique identifier for the server location or where the server is, so the operation can be performed. You have the HTTP version, the version of the HTTP protocol being used. For example, HTTP 1.1. You have headers. Headers provide additional information about the request or about the client. Your common headers include things like request body type or the authentication information that you want to send as part of your request. Then you have the request body or payload. If you are sending data over the wire, you're sending data to a server over HTTP, you most likely are sending some data across. That can be JSON, it can be XML, it can be file, whatever. And finally, you have query parameters. Query parameters are additional parameters that can be included as part of the URI, providing more information about the request. They're most likely and mostly used for operations like filtering, or sorting, or specifying other conditions. Right. So let's look at some principles of REST architecture. The first is statelessness. Statelessness is a fundamental principle of REST architecture. Now, essentially what we mean by statelessness is that each request from a client to a server must contain all information that server needs to fulfill that request. The server does not preserve the state of the client or store any information about the client state between requests. This constraints simplifies the server and simplifies the communication between the client and the server. The next is a client-server architecture. This means that all your request components is broken into a client and a server, and these two components are independent of one another. The client is responsible for the user interface and the user experience. Meanwhile, the server is responsible for processing the request and managing resources. This allows for flexibility and scalability. Now let's talk about uniform interface. Uniform interface is a set of constraints that helps to simplify and decouple the architecture. It consists of resource identification, meaning URIs, essentially. It consists of resource manipulation through representation, meaning the client can manipulate resources through the representation they receive from the server. The representation is typically in a standard format. So JSON is the most popular format. A while ago used to be XML. Another constraint you have with uniform interface is self-descriptive messages, meaning each message from the server to the client contains information needed to understand and process that message. Let's move on to cache-ability, shall we? Cache-ability essentially tells us that responses from the server can explicitly be marked as cacheable or non-cacheable. What is caching? What is cacheable? Caching essentially is a strategy you employ in your APIs to where you store frequently accessed information so that you do not burden your servers, trying to get access to that same information over and over again. So as you can imagine, that will definitely bring a performance improvement to your APIs. And so your client can also participate in that by essentially setting or getting that information from the request or response headers. The fifth principle is layered system, meaning that the architecture is composed of multiple layers, each responsible for a specific functionality, which layer must only communicate with adjacent layers. This constraint improves flexibility and scalability. According to the REST protocol, you can perform the following operations on your server. The POST is usually used for creating new resources. A GET is used for retrieving information or resources. The PUT is used for updating existing resources. The DELETE is used for deleting resources. A PATCH is used for updating existing resources. It contains only the modifications to the existing resources you want to use. Now these methods are of course supported by both native and Net/HTTP clients. Let's also look at response types. The most popular ones are what you see on the screen here, 200, 201, 202, 301, 400, 401, 403, 404, 405, 500. What do all these mean? I'm going to show you a very easy way to understand these. Everything from 200 to 300 tells you your request was successful. In fact, 301 actually means your resource has been removed. 300 is usually referred to redirected, but essentially your request was successful. They have their slight variations, but essentially it shows you your request was successful. 400 to 500 means your request failed, because of a client error. So 400 means it's bad request. So for example, you're sending the wrong parameters as part of your request. 401 means your request isn't authenticated. Your server is expecting a form of authentication key or something that your request doesn't provide such. 403 means, yes, your server or your client has provided the credentials, but the server doesn't think your client is worthy to perform that action, 'cause it lack the required roles and permissions. 404 means resources wasn't found. So the client is looking for something that doesn't exist. 405 means client is sending the request, but with the wrong HTTP method. I can go on, I know there's 406, 407, 408, 409, and and all that. These are the most common ones that you would get. 500 means it's an internal server error and indicates a server failure. Now if you want to learn more about the HTTP protocol, you can visit the RFC, that's RFC 7231. And they may have provided here on the screen, and you'll get more information. In the next video, we will be learning about HTTP client, particularly the Net/HTTP package. Seeing you in the next one.