What is a RESTful API? | Creating a REST API with Node.js

welcome to a brand new series on this channel in this series we'll have a look at how we create a restful api with nodejs let's dive right into it so let's start building a restful api with nodejs and for that first of all let's have a look at what exactly a restful api is what it's made up off and what we should keep in mind whilst we build it so what is a restful api actually well restful stands for representational state transfer and the whole idea behind a restful api or behind that name really is that we can use it to transfer data around now that sounds bigger than it maybe is the general purpose of why we want to use it is that it's an alternative to a traditional web page for cases where that traditional web page just doesn't fit our needs let's maybe have a closer look at this so what is a restful api imagine we have a client which is our browser so we are the client and we have some server obviously like a web page there we send a request for example if we enter something into the URL bar and we get back a response and for a normal web page as you know that's a couple of HTML pages 40 different URLs we enter so we have a starting page we have a products page an order page something like yet that is a traditional web page now if you're building a single page application it's going to be a bit different there you also send a request and you get back a response but you really only have to step only once because you get back one HTML page which contains a bunch of JavaScript in the end that will then dynamically re render that page but this is how web pages work now that's great for a traditional web apps but what about other cases where we also want to reach out to some server but where we don't really need HTML let's have a look at some of these cases we still got a server and by the way a server here also means that we probably have some database running on the server or running on another server but connected to this server and now let's have a look at different clients maybe a mobile app running on our smart phone and that mobile app obviously all needs to store and fetch data the problem just is it doesn't need HTML for that the data is not transferred as a text file or something like this or as HTML file I should say instead we use some other data format and we really are just interested in that data a similar case is if our client is some code some application think of the Google geo location API where we can send coordinates and we get back a parsed address for example that all there is a restful api just to give a little spoiler here and the idea here is that once you of course need to send data and get data we're not interested in an HTML page we just want to exchange data so that we can use it in our code and finally I already mentioned it the single page application case here we actually have a web app but only for the first request we need HTML for all subsequent requests we only want to exchange data send some data to the server fetch some data from it and therefore here we all just need one HTML page and no more thereafter you can't build all of that with a traditional server-side setup because a restful api in the end is also just a normal server the big difference in the end is that we don't care about this HTML stuff we just want to send data back and forth and that restful api is are stateless backends they don't care about the individual client which connected to it so if we have our client here and we have our restful server which is a normal server having some urls it is able to accept requests on and so on then we might have these endpoints so these are the urls supported by our servers these URLs then each might all support different HTTP words so we have get and post requests but we might also be able to support a delete request for example here to delete a user or the same for posts maybe we have a patch request that's all the HTTP verb which exists or for products maybe just a get request so this is how our restful api could look like we have a couple of URLs and each URL then possibly has a couple of different HTTP words and therefore types of requests it supports and then from our client we can send a request if we're having a web app we would call this an ajax request a synchronous HTTP request one where we don't send a request that get back a new page but one where we send a request our current page keeps on running and eventually we get back a response which we then if we're talking about a web application typically handle with JavaScript to re-render the dom or do whatever we need to do with that response and if we have some other kind of application like a mobile app then we still would have some tools provided by Java or Swift whatever it is whatever you use for writing that app that would be able to send a request and handle a response you get back this is the idea behind the restful api we have a server with urls supporting different types of HTTP requests for the given urls but all we do is we exchange data now if we have a look at this setup here this data is typically exchanged in JSON format it's not a must though you can send XML data URL encoded data like where you have like query parameter style foreign data you're not limited to Jason I'd say the one thing you typically always have is you're not sending HTML around though theoretically you could also do that and parse it but not with the goal of rendering it through the browser because these API endpoints here not going to get targeted directly by the browser in a sense of the user entering any of these URLs that's not going to happen all these URLs are going to be targeted by background requests like XML HTTP Ajax request sent from JavaScript or the equivalent for a mobile app this is how we use it and we use it to exchange data because that is essentially the only way we can connect a single page application or a mobile app to some back-end they don't want HTML they want the data they want to send data to so this is the idea behind a restful api now if we go into theory land here then this is not necessarily a restful api a restful api is a clearly defined construct and just having a couple of URLs with different supported HTTP endpoints it's theoretically just a back-end and an api you create it we often call all these API is restful though because it's the word or the expression for a back-end that is not a traditional server sending back HTML but data but theoretically we got a couple of constraints that really turn an API into a restful api we have six such constraints where one is optional I know this is really theoretical we're also going to build one in this serious so that it's a bit easier to grasp I guess so the first constraint is a client-server architecture if we're building a restful api then we have a clear separation of concerns between our back-end which is there to manage data do calculations and send us back data and our front-end which could be a single page application or a mobile app which is responsible for the UI our restful api awls is stateless so we don't store any client context like a session on it that's super important our restful api doesn't care about the clients connecting to it it doesn't care if it's reached by a single-page application and the mobile app and maybe some other application it doesn't store anything which clearly binds it to one of this applications like a session it's not handling sessions it's not it's not caring about sessions and this is going to become important when we add authentication we have cache ability in a sense that a restful api typically should also well express itself or tell the client whether responses can be cached or not and this is all the kind of case if you don't explicitly set up and there's just some default going to get used but you you can clearly define if for example for a get request you want to cache the response you want to allow the browser to cache the response and for how long that should be the case or if you would absolutely want to for a bit any caching because you know that your data changes so frequently that caching doesn't make sense so you can set up caching responses here too to really make sure that the client is using the API in an efficient way and this is just something you yeah you can do in a sense of you can clearly tell that caching should be enabled for example we also can build our restful api in some layered system which means the client connects to some server but that server doesn't necessarily have to be our final API could be some in-between server which forwards the requests or which sends back a response but behind the scenes also reaches out to our API and as I said we're really in theory land here but we just don't have to guarantee that our restful api or we don't give to guarantee I should say that our restful api is the final point in a traveler or in the journey of the request coming from the client we also have a uniform interface which means that resources are identified in in requests so we send a request to let's say slash users and and a get request that clearly identifies one resource the users get resource and that the data we transfer can be decoupled from the database schema so if we store a user in a certain way in the server-side database we don't necessarily have to transfer it like this to the user we can deviate from that schema although it's good if we have self descriptive messages and links to further resources for example if we send a request to get users we would probably get back a list of all the users and then it would be really good if for each user object we don't just get let's say the ID but we also get a link to which we would have to send a subsequent request to get the data for that user so that we don't have to guess about the API endpoint we would send a request to because there is something crucial to keep in mind of course when you're building an API you only have these addresses you only have these URLs and if you're not aware of them if you have no documentation to look it up and if the API doesn't send information about other addresses back in responses then you have no chance of using that API because how would you know to where you send a request if you compare it to a web application a traditional what I mean where you have multiple HTML pages there the user would navigate around with links so there we also have that information about other pages we can wizard and it's kind of the same gear for the restful api it's good if we provide this information back to our clients and then optional request is code on-demand that means that theoretically it would be allowed and still be a restful api if we implement it such that it gives the client back some executable code and that's not something we're going to build here so it really just means it doesn't have to be just data it could also be some code that the client can execute raw than just data for that code and again D is here these constraints are all just theory constructs so these are really just that's the theoretical definition of a restful api we're going to build one here and we're going to build one that works and that makes sense so don't don't learn that by by hearts that you don't need you know all of that be aware of that stateless thing is really important the clear separation between client and server dad seemed to be the most important things to me because that's something which often is hard to grasp and you often get asked well how can angle or your angular or a single-page application how can I create a session on the server and the answer is you can't really do that because in a single page application you use a restful api because you only need the data and a restful api shouldn't really care about the client connected to it shouldn't really manage sessions because you never reload pages anyways so that's important to know you're independent from the client you're stateless now enough of the theory let's build a restful api in the next video

Channel: Academind

Views: 564,389

Keywords: node, node.js, rest api, restful api, node rest, tutorial, maximilian schwarzmueller, maximilian schwarzmüller, full course, node tutorial, rest api tutorial, node rest api tutorial

Id: 0oXYLzuucwE

Length: 14min 58sec (898 seconds)

Published: Tue Nov 28 2017