O que é API? REST e RESTful? | Mayk Brito

Heyyy Dev, everything okay? Mayk Brito here, so we can study a little bit about API, REST and RESTful today. Alright?

Let's understand what these words mean a little bit, that you may have already seen somewhere, right? We're also gonna create a little API, fine? With node and express, following the REST patterns so we can be RESTful, alright?

Dude, let's start by understanding what an API is. I'll show you a very practical example. You came to see this video today.

Alright? You took your smartpohne, your pc, you got on your pc and got to this video. What was the path you used?

You went on YouTube, and you typed "learn node, learn API how API works, I want to learn API" something like that, right? Or you typed "REST" and "RESTful" and you got to this video and then started studying. How did this work, have you ever thought about this?

That you type there a keyword and THIS comes back to you, this content shows up for you until you can see this content. This idea will be so nice, man. Let's think you're on a table, at a restaurant, cool?

so you're a costumer, okay? A client and you're there waiting to have your order taken, and a waiter comes to take your order. Alright?

So there will be a waiter, and what is his function? It is taking your orders, alright? and take, or send, whatever your orders to the kitchen.

Alright? And we have the kitchen, okay? This way we will understand what an API is very easily.

So, there's the costumer, you, and the waiter is the intermediator between you and the kitchen, right? the costumer, we can understand that he is the client, that is really the client. Okay?

It can be the app on your phone, or it could be the web page, Alright? There, you said all your orders, and the waiter is our API, Okay? It is our API, that will take the orders and take them to the kitchen, that is our server.

Alright? Our server. Simple as that, it's really easy.

You've already understood what an API is. Of course, we have the more complex terms, right? so "API" right, what does it mean?

It is an acronym for "Application Programming Interface" that would be an interface for programming applications, which is basically a group of routines and patterns that an application offers us so that other applications take this information. So, bringing these to practical terms: You created your API, and see, you've got YouTube's API. Okay?

you created an app, a client, that will use YouTube's API, alright? so it can bring little videos to your app. so you created your app, and you're gonna "talk" to YouTube's API, and it will bring its information to your App.

Simple as that. This is how an API works. I'll leave everything I said here written.

Alright? Then you-- you can take a look. So, for us to understand what an API is: It is responsible to establish a communication between different services, did you get it?

you've got your services, and you're using YouTube's services, Instagram's and Facebook's, alright? you understand that it is a halfway between these technologies, okay? I'll also note this.

. . "halfway through the technologies" it is an intermediator for this information share.

so there it is, you understood what an API is. Okay? Now let's understand what RESt is.

uhm. . .

you've got to understand this: so you got to the restaurant, right? and you want a *clean* restaurant. Right?

you want a restaurant that serves you well. you want a restaurant that. .

. a restaurant, you want a restaurant that gives you exactaly what you ordered. Alright?

The same goes for you, you can't enter the restaurant yelling, ~hehehe~ you can't enter the restaurant cussing, ~hahahah~ Alright? That's mean. So what were we talking about?

Good manners. Isn't it what we're talking about? we're saying like, "man, let's respect some things, and everything will go smoothly" Alright?

THIS is REST. It determines It. .

It determines some obligations on this data transfer. Alright? Cool, isn't it?

See, the data transfer we talked about, that the API does for us, okay? it is done, usually, with HTTP protocol. Alright?

I'll put it like this, "the data transfer. . .

usually using the HTTP protocol" Alright? So, the REST, says something like this: "dude, we need some rules, some obligations, for this data transfer, okay? in clearer way, explaining what REST is, it is also an acronym for "Representational state transfer" alright?

Representational state transfer. Okay? What is a representational state?

What does this mean? it is a data transfer, alright? in a.

. . representational way.

Alright? In a didactic way, let's say it like that, in a didactit way. Alright?

I'm writing this so you can take a look later. So REST, it encoloses, like I said, some obligations in this data transfer. alright?

So, what are these obligations, these data transfers? Beefore we talk about what they are, just so we con understand the data, here on REST, let's call it Resource. Alright?

Resource would be an entitiy, an object, and soon we wil see HOW these data are transfered. But just so you can nderstand that there IS a data transfer. In this case that I talked about the restaurant, the costumer (client) is ordering, and the waiter is taking the orders and writing them on a little order pad and taking it to the kitchen, and telling the cook, showing the order and saying "I need this dish right here, for table number x", and so on the way he's doing it is through an order pad, a note pad.

We already know that our notepad would be HTTP and then we'll see how we write this on the notepad. Really simple, right guys? [giggling] I guess understanding REST, RESTful and API was never this easy, alright?

so there are, six constraints, that we call it like this, that are obligations, okay? obligations. Six constraints so you can be RESTful.

Alright? So you can be RESTful. I'll tell you right now, I'll show you what it is right now.

Being RESTful is following the REST patterns, Simple as that, you've already understood what RESTful is, no need to worry about it, okay? being RESTful is applying REST patterns. What are these patterns?

We will study this RIGHT NOW. okay? Here it is.

Six obligations okay? to be RESTful. Let's go.

First: Client Server. Alright? Client server, easy to understand.

The client AND the server have to be separated. This way, we have a system portability, the client can be anything, Alright? once I'm.

. . uhm.

. building an API so that other people can use it the server it is. .

. it's the only one there but there is the API and is being separated which means, I'm not on a frontend interface from YouTube so I can take information. I'm receiving this in another way, alright?

I'm taking the information from the server, form the API, and soon we'll see how it is done. So, you've already understood what separating the client from the server is, okay? The data from the client and from the server.

Simple as that. Using, bringing this to our reality here, using React for web, or React Native, these are clients, and Native will run on your. .

. on your smartphone and Web will run on your pc, alright? These are practical examples, of how they are separated.

and they are consulting an API on YouTube there, and you're not even seeing it, how it works, you simply are consulting these information. and then, it goes with another . .

uhm. . .

constraint, with another obligation named Stateless. Stateless means it is stateless, (explanation in Portuguese here) "What is this, Mayk? Wow, now you've confused me" Dude, each order I tell my waiter, the waiter needs to know that he has to bring the order back TO ME.

So, think of it as being that each order I tell my API, everytime that I call my API, this order has to be complete, with every information the server needs. Okay? The server needs to have all the information so it can bring your order back in a .

. . uhm.

. . correct way, the way I ordered it, fine?

That's it. You've understood what stateless is. So, each request the client has for the server, it must contain all the information the server needs to understand and answer.

So, I'll put two little words right here, okay? "Responding to the Request". "Response" and "Request".

Each time you see this little word right here on our class, "Response", you'll understand that it is "responding" (explaining on Portuguese) and "Request" is the request. Okay? (Still explaining in Portuguese) So you've got what stateless is.

Alright? one more practical example, is the user's session. so, we go there and start the user's session, but, everytime I access the API again to asl for data, I need to send this user's session.

The server can NOT store this information inside. Alright? I have to send it back again.

That's what stateless means. If the server stored it inside, then it would have a state inside. It can NOT have a state.

So, Stateless, means, without a state. Okay? Veeery simple, right?

I'll right this one for you too". (Reading what's written) "For example, the user session must be sent in all requests, in order to know if that user is authenticated and able to use the services". Simple as that.

Okay? (Reading) "and the server can't 'remember' that the client was authenticated on the last request" Exactaly how I said. (Reading) "on our courses, for example, we have as a standard to use tokens for communication" Alright?

For the communication the tokens will tell if the user is authenticated or not, once this API, this path is closed, right? if it is an open path, an open API, I don't need to send this session. But, I need to send enough information to the server uhm.

. . resolve itself back there, without storing any state.

Fine? Everything has to be on my request, on my order. Very good.

Next, And see, by understanding these you're already closer to being RESTful, do you get it? you're responding well to the obligations, to the constraints, to REST's obligations. So, next: Cacheable.

Easy. The respones, for each request you make, they have to be explicit if they can be cacheable or not. By applying this, way to go for being REST.

Really cool, isn't it? Layered system. I'll write here, "Layered System".

System in layers, okay? Explaining in Portuguese) the client will always access an end point, alright? "What is an end point, Mayk?

what is an URI, an end point, what's all that, dude? " okay, it's simple, I'm here, "https", for example, "graph. facebook.

com" "/" idk, youtube. Alright? THIS right here is an end point.

This is the path it is getting to, on this case right here, graph. facebook is an API, okay? it is an URL and then I'm adding the information I want, YouTube, I want information from YouTube.

So, this is an end point. That's it, right? That's it.

Every time you consult an API it has there its end point. so, dude, you, the client, will consult, will access the end point, Alright? And it doesnt need to know what -- how complex it is for the server to respond to me yeah, respond to the client right, that information.

So, bringing the waiter example again, "Hey, I'd like to order this dish" I don't care how the waiter is going to take my order to the server, to the cook, if the cook will need other cooks, what is it, and what is the path to get there. Right? there are layers, there are paths.

But I'm not interested to it, I just want to get my dish. I'm ordering and I want to get it. Alright?

So, it has to . . .

it has to respect these layers, in a way that the client is not aware of how complex it is back there. So, the client accesses the end point without needing to know the complexity, of which steps are necessary for the server to answer the request or what layers the server is dealing it so that the request can be answered. So you've also got this.

Next, and last, this one is optional, okay? so, if you've got to the "layered system" and done this in your API, you already are RESTful. But there is one option here that is "Code on demand".

code on demand is you sending to your client, right, the server sends to the client, some script for it to run there on the frontend. Alright? The backend, the server, sends to the client so the client can run some script.

This is optional, it can be done or not. So this gives the possibility of our application to take codes like JavaScrip for example and run on our client. Fine?

You've understood all six obligations or the six constraintss for being RESTful. if you understood these, all fine. We also already understood what RESTful is, but let's talk a little bit about good manners, but we are going to talk about good manners coding, okay?

let's code, and there we're going to talk a little bit about good manners applied to our APi that we're going to create now. Alright , dev? We're back so we can build our own API Fine?

Let's start by creating our project. Alright? I already have my folder here using "yarn init -i" Alright?

"init" will start the project, "-i" it will do it without asking me any questions. Fine? Fine, it has already started here, and it created a package.

json for me where it left here some information about my project. Alright? What we are going to use here to start our.

. . to start creating our little server we're going to use the express Alright?

"yarn add express" and we are going to add to our project the express dependency. It has already added here, notice it created a little folder named "node. modules" where all the express dependencies are and more, and a "yarn.

lock" so it can map all this for us. hmm,fine, having this all set up we are going to understand a little bit more about API building, good manners and more. Also notice that I left Insomnia oopened here, this cool app, that will make us communicate to our backend, alright?

Through the HTTP protocol, just as we talked about a while ago. Okay? So I'll create here a JS server and this server is where we will start to create our API.

I'll start by calling the express, Alright? that I installed there with Yarn Fine? and I'll e vou instanciar ele nessa variável app.

and, for me to start the server, I can simply add an "app listen" and it will start the server, alright? I want it on port 3000 with a callback function here giving me only one information, right? "console.

log", "server is running" Fine? the moment I call here the node on the server it will tell me that the server is running already. Of course, there is NOTHING here on this server, it isn't worth much (giggling).

This is where we'll understand a little bit more about our REST, a very important concept that I didn't talk a lot about, alright, on purpose, is the Resource. This is a fundamental REST concept: really understand what resource is. And this is where we will understand it.

The resource, like I mentioned back there, it is an object, an entity. Alright? It has data associated to it, and it is related to otherresources, right?

a lot of ways of operating it, and, so we can understand a little bit more about resources, we're going to talk a little bit about HTTP verbs, "(typing) HTTP verbs" okay? so we can create this communication with our resource. Resource,so ,you're going to understand it by parts, okay?

You're going to understand it by parts. Soon you will build the idea of what a resource is, because resource is sorta an abstract concept. But once we start building these little pieces, all of a sudden you're gonna go like "OHH I get what resource is".

So, the HTTP verbs, they are important for our resource building, we have the "get", the "post", "put", and "delete" Okay? we have others too, but these are the most common, alright? And each one of them tells me something.

Okay? Each one of them means something to me. And here I'll already tell you one of the good manners: it is important that you use the HTTP verbs on the requests from your API, okay?

you have to CREATE these verbs. There are. .

developers who prefer to use only "get" and "post" But it is important that we use different verbs for each application type because this way it is clearer for who is using our API, alright, for who's using our resource, what each of these things are doing. so "get" is responsible for receiving data from a resource, "post" is the one who will send data or information to be processed by a resource, keep the word 'resource' in your mind, stay calm 'cause soon it will make sense for you. "put" is the one who will update the data from the resource and "delete" is the one who will delete a resource.

Fine? so, if I reach, if my end point is, right, the local host, "3000", that is my server, okay? "/clients" now we're gonna have some fun with these clients here so I have an end point 'clients' as we talked about back there, Alright?

I have my URI, that is this full path, okay? and I can say that clients is the name of my resource. Okay?

I can say that. so once you switch this one for the name, "get", so it will receive data from a client in this specific case, okay? or if it will send data or information to be processed in this client, okay?

From this client. the "put" will update the data from this client, and "delete"will delete a client. It's a little bit more clear now, right?

But you'll see that resource doesn't end there, it has a lot , like I said before, a lot of other factors, so, the URL, this URI is NOT a resource, okay? it is a little name, let's say it like that, it is a name to reach, it's where I call the waiter, Alright? He will make the data transfer, the data will go through here, okay?

But it doensn't mean it is a resource. and you also remember me mentioning that there is a notepad, this waiter has a notepad to write the orders, okay? uhm.

. how does he write on it? We will see this soon.

But now let's think, this resource will be the notepads, alright? It will be the notepad. The clients notepad in this case here.

Fine? Just for educational purposes. Let's go.

So, on express, For me to use the verbs is really easy, I can add an "app get", okay? "app post" "app put" e "app delete". Here you go.

The verbs are already settled here on express so we can use them, fine? Here we got through a good manner, and also, I'm gonna update my good manners pad, Okay? and a good manner is: Using HTTP verbs for our requests.

Okay? and a few verbs, that I mentioned here, are these. Alright?

A few of them. Very good! now, let's just add the end point that we'll use, that is "/clients".

okay? another good action, and it's also an information, is that we shouldn't use "/" at the end you're free to use it, but it is a good action not to use "/" at the end of your end point, Okay? and also, another good action, right, and another doubt usually asked by developers is: "should I use it on plural or on singular?

Should I use 'client' or 'clients'? " The answer is : it doesn't matter, use that. .

. use a pattern, if you use 'client', your next resources that you'll create, being whichever, "post", "user", "post transaction", if you're going to use on plural, use everything on plural. Okay?

Just keep it like that. I'll also update our little friend good actions here, So, using plural or singular, whatever, it doesnt matter, use a pattern, and dont leave a "/" at the end of the end point. Very good.

Here we already took a step on the creation of our resource. Okay? Another interesting thing, is that sometimes you'll want to take one single client you can put the ID here, that is a parameter, Okay?

For you to take a single client. Just like on "put", you will update only one client. So it is important to add this, and "delete" will delete a client, it is important to add this too.

Cool? Done. Now, express allows us to add a callback function, which is what is going to process ~I'll put it like this~ the function, which is our callback function, and it will process our request.

and obviously, I need to take my request, right, my waiter will take my order, my request, and will give me a response. Okay? so, these two parameters are important and should be talked about here.

We use, by standard, "req" and "res". Eeeasy. You already know that one is the request and the other is the response, that after I process my request I will obtain.

So, to finish what is the concept of resource, we have right here what's being noted, right? Untill now, we're building our notepad, okay? from our little waiter.

We are building our resource. But now, what about the data? how are they being noted?

back then, we usually used the XML notation, and nowadays we use json, alright? which means "javascript object notation" it is a way of noting javascript objects. Really easy.

Here, just so we can understand this a little easier, I'll access this. . .

on my browser I'll access this URLright here ant it will bring me users, okay? it will bring me fake users ~hehe~ from this API here. and I'll create a.

. . a new file here named "data.

json", okay? and I'll take the users from that URL easily, and here I already have the data from my resource, this is my client resource. Nice, one more thing, I'll call this data here of course, on your.

. . on your application, there will probably be a connection with the database, right ?

you'll get this data through another way, it wont be fake like this, but here, you have the data, and now, once I ~"get", as we have seen before, gets information (explaining in Portuguese)~ clients, so I have to answer my clients here. But the express needs it needs then to use json. That's it, I'm telling express: "use the json notation for me, alright?

and here I'll have the answer now, in json format, okay? simple, from all my clients. Okay?

Look how nice it is, we already started our application really well. if I send here a node server my server is running and now I can access the "/clients". Using the Insomnia, I'll create a little folder so I can be very didactic, "Clients" just so I can know this is my clients resource, I'll add my first request, which is all the clients, 'take all the clients' Okay?

Fine? So, you don't need to send a body, but your only need to get to the end point, right? "localhost.

3000/clients" Okay? When I send, Looooook how nice, I got back all my clients. And here enters one more concept that I wanna show you with this 200 here, okay?

it is a concept, a good action, is the concept of ALWAYS leaving clear answers to your client, and the good action is never to leave a client without a response, alright? ALWAYS respond. Ad then, let's take a look at the responses's status.

You already spotted one there, the 200 status, and I'll add it here for you , and then you study this a little bit, when you're building your API it is always good to give this a little check so you can send clear responses to the client. Think about this one: you created your API and there is someone, uhm. .

. there is an app, on the USA, using your API. consumindo a sua API.

Those developers, Aqueles desenvolvedores, they are not really sure of how it was done, of what's going on on your server. So , it is important that these responses are clear, and that's why we have the status of the responses on HTTP. where the '200', the "ok", it says that my request was served perfectly, everything is fine.

. . But there will be a moment, that I only need to state that it has been created, that it doesn't have a content, right?

Usually, on 'put', on 'post' and on 'delete', sometimes they don't have the content that you're looking for, I have to tell my client that he made a bad request, right? "Hey, there is some data missing on your request", then, here, I send the response status, and I need to tell my client if that path was found or not, for e. g.

, if I send here a client, now, so, it doesn't exist, so, 404, it wasn't found, so my client knows "maaaaan, I'm accessing a path that doesn't exist" And the 'server error' sometimes, there will be an error on our server, some code thing, and then I'll tell my client: "hey, chill, you've done nothing wrong, But, there is an error here, okay? We'll try to fix that. " Fine?

Really easy, right? so, by sstandard, you saw that 'res json' directly like this, it will always answer 200, Right? Always 200.

Fine? So, uhm. .

. how will we communicate better? I'll do this communication example right now, here on this "take the client" part, okay?

Really easy, uhm. . .

I need to take the ID, from this client, so, I, have this ID avaliable to me. on my 'req', which is my request, ". params", Okay?

that are the parameters of the request. I could have several different parameters, right? I could have the 'post ID', right, and all of this I could be taking with my uhm.

. . 'req' 'params', alright?

It would be avaliable for me there. In this case, All I need is the client ID, okay? and I need this client ID so I can take a client.

it is "= data. find cli" ~haha~ alright? "cli ID" equals ID.

so, I'm telling it this: "hey, get me a client, , whose ID is equal to this one I'm asking right here, and put it on my client variable, alright? and answer me the client. Cool?

So I'm requesting only one client, let's restart our server, and let's call this client I'll double this one, and call it single Alright? so I can know it is a single client, and I'll call just ONE client. the client number one responded, nice, that's nice, right, so it's working.

But what if I ask for client number 15? Aaand it doesn't exist, and see, what I mentioned: the standard is to always respond "200". But it doesn't have (client 15), and I need to respond to this in a different way, to the person who's using my API, And I could tell them this: if there is no client, "return" "res.

status" , right, 204, which is "There is no content, a content for what you're looking for wasn't found" Alright? I wouldn't use 200-- I wouldn't use 404 not found, because this path, it exists, okay? This path exists.

What doesn't exist is the client's content. So, I could put this, but it's up to you how you are building your path, okay? If you want to use 404 here, right, for your client, it says "man, this doesn't exist, it wasn't found" it's fine, right, but let this really clear on your application.

Alright? Uhm. .

. Very good. Moving to the next, now we'll understand how we'll get more information uhh.

. being sent from our client to our backend. So now, I'll tell the waiter, I'll give more information to the waiter, right, to-- that are 'post' information.

Alright? So, to save a client on this case. How does this work?

I'll create here on my Insomnia a new request that is "store" right, to save a client, and I'll send it as a post, and, it's saying that it doesn't have a body. No, I need a body, and my body is a json, alright? so I'll send these information, for example, my name.

okay? and my e-mail. So, I'm sending this, "and how can I take this here, Mayk?

" Dude, I can take only the name, and the e-mail, from my req body, alright? No problem. I can take just this, And then I'll make here all my my logic of saving a new client, okay?

And I'll respond with an ok status when I save, sending the name and the e-mail back to my client so it knows everything went fine, that I saved this content in a good way. Alright? let's see what happens now when I send this to my local host "3000" right, /clients.

You realize that the resource's path is the same , right? What is changing is the verb, can you see it? Of course, there was a time that I would work only with 'post', and I would use "client.

update" and that's not good, right? ~hehe~ only clients. So I'm saving a new client, so, 'send', and it responded me with "200", okay, it saved, I did my routine of saving, and it showed me that the client was saved.

cool? Really easy. Next it will be updating my client.

Right, let's see what would be a little routine of update, that we could work with the update part. Update, and I'll need the ID like I said, right, and I'll also need to take my client. So I'll copy that line and then I take my ID from my parameters, I'll take my client, and I'll find my client.

I can use the same logic, like, "man, I didn't find the client to update you, alright? " and then, if I found a client, I'll take it too, alright? My body's name and e-mail, right?

My body's name and e-mail. But in this case I'll only take the name, okay? So it will be more simple.

I'll take the name, then, "client. name" is equal to the one I took from my body. Fine?

res. json, so everything is fine, it responds an updated client. uhm.

. . I'll restart my server, I'll duplicate my.

. . it can be my 'store', no problem I'll duplicate it here, and I'll write --- oops, 'get' got duplicated.

No problem, I'll type here "update", Alright? it is a "put" type and on this path, it has a body, that is json, and I'll update the name. which is -- Which is Mayk.

Okay? So, If I get all these new guys right here, I have client number one, named "Leane", But now I'll call it Mayk. So, Client number one is Mayk.

There, it updated to "Mayk". All fine? very very very easy, sweet Good, ~hehehe~ so now, let's Do that routine of deleting a client.

Right? just joking. so I can do this, look: "clientsFiltered" because I'm using the idea of filtering things, Okay?

My clients and I'll tell it to bring me all the clients with an ID different from the ID being showed here to me, okay? Which means, I'm taking off the list ~hehe~ I'm taking off the list the ID being showed here, and it will give me a new list back, right, with. .

. with the filtered clients so this way I'm deleting a client and just joking, alright? From my API.

Sweet, now I can duplicate this guy too in a way of deleting client number one and I don't need the body, and it's fine, it's all right, and I can send, and here it is, it sent the new list, with the ID of 2, 3. . because I deleted ID number one.

Of course, let's change this name here too, so it won't be weird, "destroy" Alright? So, see how easy. Okaay, it is a mess, but as I said, it is nice to start by separating the files, organizing everything so the start of your app is not a mess and we only have one resource, that is of clients, imagine with three, four resources, this would be a total mess, But I really hope you understood What an API is, in a very simple way, REST and RESTful, okay?

API being the one who's gonna do the communication, for us, between the front and backend, the REST, that are a few rules, and RESTful that is the usage of these rules, right? And this way we have a little API working I hope this makes sense to you, leave it down a comment what did you think about this, what could we improve, what you don't understand at all, that this is all a mess, but who knows, we might talk a little bit about this later. Alright?

A huuge hug, a lot of success, and see you on the next video!