What is an API? What is REST? Learn how an Application Programming Interface (API) can adhere to Representational State Transfer (REST) to enable reliable communication between apps https://fireship.io/tags/node/

👕 Best comment wins a free T-shirt (read fine print at end of video)

Open API Spec https://swagger.io/specification/
Request Methods https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods

#api #js #100SecondsOfCode

Install the quiz app 🤓

iOS https://itunes.apple.com/us/app/fireship/id1462592372?mt=8
Android https://play.google.com/store/apps/details?id=io.fireship.quizapp

Upgrade to Fireship PRO at https://fireship.io/pro
Use code lORhwXd2 for 25% off your first payment. 

My VS Code Theme

- Atom One Dark 
- vscode-icons
- Fira Code Font
2024-02-04T14:17:46.056Z
nova-2
2-general-nova
2024-01-09.29447
30089e05-99d1-4376-b32e-c263170674af
40796129-da12-4995-abe4-1db99f5fecac
40ca234d416f21369caff16da58188497738e1d54c1b94f533bcfb0df09ecbfe
67875a7f-c9c4-48a0-aa55-5bdb8a91c34a
deprecated
An application programming interface or API is a way for 2 computers to talk to each other.
Using an API is just like using a website in your browser, but instead of clicking buttons and filling out forms, you write code to explicitly request data from a server.
For example, we could visit the NASA a website to look at asteroids, or we could use their rest API to request the raw JSON data that is shown on the screen.
Now most APIs in The world are restful, which means they follow a set of rules or constraints known as representational state transfer, which has been the de facto standard for API development since the early 2000.
A restful API organizes data entities or resources into a bunch of unique URLs.
Well, technically not URLs, but u r i's or uniform resource identifiers that differentiate different types of data resources on a server.
A client can get data about a resource by making a request to that endpoint over HTTP.
The request Message has a very specific format.
Most importantly, the start line contains the URI that you wish to access, which is preceded by an HTTP verb or request method, which signal your intent with the resource.
A git request means you just want to read the data, while post means you want to create a new resource.
Patch is for Updates, delete is for removing data, along with a few other methods beyond those.
Below the start line, we have headers, which contain metadata about the request.
The accept header can tell the server you want the data in a specific format, or the authorization header can be used to tell the server that you're actually allowed to make that request.
Then following the headers, we have the body, which contains a custom payload of data.
The server will receive the request message, then execute some code, usually to read from a database, that can then be formatted into a response message.
The top of the message contains a status code to tell the client what happened to their request.
Codes at the 200 level mean that things went well.
At the 400 level, it means something was wrong with your request.
And at the 500 level, it means that the server failed.
After for the status code, we then have the response headers, which contain information about the server.
That's followed by the response body, which contains the data payload and is usually formatted in JSON when talking about APIs.
Now an important part of this architecture is that it's stateless, which means that the 2 parties don't need to store any information about each other, and every request response cycle is independent from all other communication.
And this leads to well behaved web applications that are predictable and reliable.
This has been restful APIs in 100 seconds.
If you enjoyed it, leave a comment below.
Then next week, I'll pick out the best one to win this free t shirt.
And now it's time to go beyond 100 seconds to build a restful API from scratch.
The most popular framework for building restful APIs in Node is Express JS.
It's been around forever and it's very minimal and easy to learn if you know a little bit of JavaScript.
Over the next few minutes, we'll use Express to build our own restful API from scratch.
You'll learn how to create different endpoints for your API.
We'll also look at slightly more advanced concepts like middleware and tools in the cloud for deploying your API like API gateways.
To get started, you'll want to open up Versus code to an empty directory.
You'll need to have Node.
Js installed, and I'm using version 12 for this video.
To start a new Node project, let's run npm init y from the command line.
This will create a package JSON and give us a context for installing packages that we can use in Node like Express.
Let's go ahead and install Express using npm install.
You'll notice that adds express to our dependencies in the package JSON file.
From there, we'll need a file to write our code in, so let's create an index dotjs file.
At the top of that file, we'll declare a variable for app, which represents the actual API that we're building.
And its value is an import of the express package, which itself is a function, so we'll add parenthesis after it to initialize it.
Now at this point, our API has in to find any endpoint, but let's go ahead and run it anyway.
The way you fire up your API on the server is by calling app dot listen.
That tells it to listen on a specific port, which we've defined as its own separate variable as 8080.
Then as an optional second argument To listen, we can fire a callback to let us know when the API is ready, and we'll just have it console log the main URL.
We can now run the API by going to the terminal and running node period to run that index dot JS file.
And it should console log, it's alive on local host 8080.
If we paste the URL into the browser, you can see we get a message of cannot get.
That's because we don't have any API endpoints set up yet, but Express is still responding with an error message.
In fact, you can open up the network tab in Chrome.
If we look closely, we can see that our server responded with a 404 status code, meaning that page was not found.
At this point, we know our API is working, but debugging it in the browser is usually not the best option.
There are many different ways we can access our API.
We could use curl from the command line, we can install a Versus Code extension, or we could use a REST client like Insomnia or Postman.
I'm going to be using Insomnia throughout the rest of this video because it provides a really nice way to format your requests and also via history of all your interactions.
From Insomnia, We can create a new request, then simply paste in our URL.
We can easily change the HTTP verb from the drop down menu here, Click Send and then get the response in a nicely formatted developer friendly way.
We can even see the timeline here with our request in yellow and the response in green.
But now we need to get back to our JavaScript and add an endpoint to the API.
We can do that by chaining an HTTP verb to the app instance.
If you type a period after app, you'll get IntelliSense on a bunch of different methods that live on this object, and you'll notice methods for git, post, patch, etcetera, which represent different HTTP verbs.
If we want to add a git endpoint to the t shirt URI, we can do that by passing /tshirt as its first argument.
That'll automatically set up our server with that endpoint, then it's our job to handle a request to it, which we do by passing a callback function as the second argument.
Whenever a client or end user requests that URL, it will fire this callback function to handle the request.
The function itself provides access to 2 different objects, the request object and the response object.
The request is the incoming data, while the response is the data we want to send back to the client.
The most important thing it does is allow us to send a response back to the client.
That response can have a status code like 200 for an okay response, then we can send a data payload along with it.
If we pass a JavaScript object as the argument, then it will send that data back as JSON by default.
Let's go ahead and save the file, then restart server from the terminal.
From Insomnia, we can then make a get request to local host 8080/t shirt.
When we do that, We get a JSON object back as the response body with a status code of 200.
That's pretty cool.
But now let's go back to our code and add a second endpoint, This time, a post endpoint followed by a slash and a dynamic URL parameter that represents the ID of that t shirt.
There might be millions of different t shirts on this API and a dynamic URL allows us to handle all of them from a single function.
When dealing with a post request, It means that the user is trying to create new data on the server or create a new t shirt in this case.
First, we need the ID, which we can get from the URL, and its value is made available to us on the request parameters object.
2nd, we also need a logo for the t shirt, But the logo is contained in the request body, which if you remember from earlier, is a custom data payload contained in the incoming request.
In other words, the request Object and Express allows us to access information from the request message, like the URL parameters, the body, the headers, etcetera.
And now that we have that information, we could use it to save a new record to the database or something along those lines.
That's beyond the scope of this video.
What we'll do for Right now is check to make sure that we have a logo in the request body, and if we don't, then we'll send an error response with a 4 18 status code and an error message that we need a logo.
But assuming we do have a valid logo, we can just send a response with a t shirt that contains that logo and ID.
Now let's go back to Insomnia, and we'll make a post request to that t shirt endpoint followed by a unique ID that can be whatever you want.
Then in the body section, we'll go ahead and add a request body with a format of JSON, and it's just a JSON object that contains a logo with a string value.
If we send that request, you'll notice we get a 500 error response, which means our API code is broken.
So what's going on here?
It's telling us we have a runtime error because we can't destructure the property Mogo from the request body.
The reason for that is that Express does not parse JSON in the body by default.
Not everybody uses Express to build a JSON API, so that's not the default behavior.
What we need to do here is set up middleware that tells Express to parse JSON before the actual data It's the function that we're using here to handle the request.
When you hear the term middleware, think of shared code that runs before every endpoint callback Mac, that you've defined.
Very common middleware is built into Express itself.
We can refactor our code here a little bit to make a variable for Express, And then we can call app dot use to apply middleware.
In this case, the middleware we want to apply is the express dotjsonmiddleware.
Now every request that comes in will first go through this express JSON middleware, which will convert the body to JSON, therefore, making it available both in our post callback.
Let's go ahead and save, restart our server, and then go back to Insomnia.
And if we send the same exact request, you'll notice this time, We get back a successful response.
In addition, if we make the logo an empty string and try to send the same request, We get a 4 18 response along with a message that we need a logo.
Congratulations.
You just built a restful API from scratch with no JS and express.
But before we wrap up the video, there's one more thing you should definitely know about when it comes to restful APIs.
And that is the open API my spec, which provides a standard way to describe an API in YAML.
It originally came about in something called the swagger framework, and what it allows you to do is describe your API in a way that can be understood by both humans and machines.
And if you're building a serious API, you get all kinds of awesome benefits in the process.
Your API will be fully documented, making it much easier for the end user to work with.
And because it follows a standard format, you can actually just automatically generate all of your client side or server side code.
What I'm using right now is a free tool called Swagger Hub, and I can come up here and hit the export button to automatically generate a bunch of boilerplate code.
Now I'm usually not a huge fan of code generators, but there's a more powerful reason to use OpenAPI.
When you describe your API With the open API spec, you can then upload the configuration to tools like API Gateway on AWS or Google Cloud, where it can be secured, monitored, and connected to back end infrastructure.
Let me know if you wanna see a full tutorial on that topic, but I'm gonna go ahead and wrap things up there.
And if you want access to even More advanced content, consider becoming a pro member at FireShip IO.
Thanks for watching, and I will see you in the next one.

Speaker 0: An application programming interface or API is a way for 2 computers to talk to each other. Using an API is just like using a website in your browser, but instead of clicking buttons and filling out forms, you write code to explicitly request data from a server. For example, we could visit the NASA a website to look at asteroids, or we could use their rest API to request the raw JSON data that is shown on the screen. Now most APIs in The world are restful, which means they follow a set of rules or constraints known as representational state transfer, which has been the de facto standard for API development since the early 2000. A restful API organizes data entities or resources into a bunch of unique URLs.

Well, technically not URLs, but u r i's or uniform resource identifiers that differentiate different types of data resources on a server. A client can get data about a resource by making a request to that endpoint over HTTP. The request Message has a very specific format. Most importantly, the start line contains the URI that you wish to access, which is preceded by an HTTP verb or request method, which signal your intent with the resource. A git request means you just want to read the data, while post means you want to create a new resource.

Patch is for Updates, delete is for removing data, along with a few other methods beyond those. Below the start line, we have headers, which contain metadata about the request. The accept header can tell the server you want the data in a specific format, or the authorization header can be used to tell the server that you're actually allowed to make that request. Then following the headers, we have the body, which contains a custom payload of data. The server will receive the request message, then execute some code, usually to read from a database, that can then be formatted into a response message.

The top of the message contains a status code to tell the client what happened to their request. Codes at the 200 level mean that things went well. At the 400 level, it means something was wrong with your request. And at the 500 level, it means that the server failed. After for the status code, we then have the response headers, which contain information about the server.

That's followed by the response body, which contains the data payload and is usually formatted in JSON when talking about APIs. Now an important part of this architecture is that it's stateless, which means that the 2 parties don't need to store any information about each other, and every request response cycle is independent from all other communication. And this leads to well behaved web applications that are predictable and reliable. This has been restful APIs in 100 seconds. If you enjoyed it, leave a comment below.

Then next week, I'll pick out the best one to win this free t shirt. And now it's time to go beyond 100 seconds to build a restful API from scratch. The most popular framework for building restful APIs in Node is Express JS. It's been around forever and it's very minimal and easy to learn if you know a little bit of JavaScript. Over the next few minutes, we'll use Express to build our own restful API from scratch.

You'll learn how to create different endpoints for your API. We'll also look at slightly more advanced concepts like middleware and tools in the cloud for deploying your API like API gateways. To get started, you'll want to open up Versus code to an empty directory. You'll need to have Node. Js installed, and I'm using version 12 for this video.

To start a new Node project, let's run npm init y from the command line. This will create a package JSON and give us a context for installing packages that we can use in Node like Express. Let's go ahead and install Express using npm install. You'll notice that adds express to our dependencies in the package JSON file. From there, we'll need a file to write our code in, so let's create an index dotjs file.

At the top of that file, we'll declare a variable for app, which represents the actual API that we're building. And its value is an import of the express package, which itself is a function, so we'll add parenthesis after it to initialize it. Now at this point, our API has in to find any endpoint, but let's go ahead and run it anyway. The way you fire up your API on the server is by calling app dot listen. That tells it to listen on a specific port, which we've defined as its own separate variable as 8080.

Then as an optional second argument To listen, we can fire a callback to let us know when the API is ready, and we'll just have it console log the main URL. We can now run the API by going to the terminal and running node period to run that index dot JS file. And it should console log, it's alive on local host 8080. If we paste the URL into the browser, you can see we get a message of cannot get. That's because we don't have any API endpoints set up yet, but Express is still responding with an error message.

In fact, you can open up the network tab in Chrome. If we look closely, we can see that our server responded with a 404 status code, meaning that page was not found. At this point, we know our API is working, but debugging it in the browser is usually not the best option. There are many different ways we can access our API. We could use curl from the command line, we can install a Versus Code extension, or we could use a REST client like Insomnia or Postman.

I'm going to be using Insomnia throughout the rest of this video because it provides a really nice way to format your requests and also via history of all your interactions. From Insomnia, We can create a new request, then simply paste in our URL. We can easily change the HTTP verb from the drop down menu here, Click Send and then get the response in a nicely formatted developer friendly way. We can even see the timeline here with our request in yellow and the response in green. But now we need to get back to our JavaScript and add an endpoint to the API.

We can do that by chaining an HTTP verb to the app instance. If you type a period after app, you'll get IntelliSense on a bunch of different methods that live on this object, and you'll notice methods for git, post, patch, etcetera, which represent different HTTP verbs. If we want to add a git endpoint to the t shirt URI, we can do that by passing /tshirt as its first argument. That'll automatically set up our server with that endpoint, then it's our job to handle a request to it, which we do by passing a callback function as the second argument. Whenever a client or end user requests that URL, it will fire this callback function to handle the request.

The function itself provides access to 2 different objects, the request object and the response object. The request is the incoming data, while the response is the data we want to send back to the client. The most important thing it does is allow us to send a response back to the client. That response can have a status code like 200 for an okay response, then we can send a data payload along with it. If we pass a JavaScript object as the argument, then it will send that data back as JSON by default.

Let's go ahead and save the file, then restart server from the terminal. From Insomnia, we can then make a get request to local host 8080/t shirt. When we do that, We get a JSON object back as the response body with a status code of 200. That's pretty cool. But now let's go back to our code and add a second endpoint, This time, a post endpoint followed by a slash and a dynamic URL parameter that represents the ID of that t shirt.

There might be millions of different t shirts on this API and a dynamic URL allows us to handle all of them from a single function. When dealing with a post request, It means that the user is trying to create new data on the server or create a new t shirt in this case. First, we need the ID, which we can get from the URL, and its value is made available to us on the request parameters object. 2nd, we also need a logo for the t shirt, But the logo is contained in the request body, which if you remember from earlier, is a custom data payload contained in the incoming request. In other words, the request Object and Express allows us to access information from the request message, like the URL parameters, the body, the headers, etcetera.

And now that we have that information, we could use it to save a new record to the database or something along those lines. That's beyond the scope of this video. What we'll do for Right now is check to make sure that we have a logo in the request body, and if we don't, then we'll send an error response with a 4 18 status code and an error message that we need a logo. But assuming we do have a valid logo, we can just send a response with a t shirt that contains that logo and ID. Now let's go back to Insomnia, and we'll make a post request to that t shirt endpoint followed by a unique ID that can be whatever you want.

Then in the body section, we'll go ahead and add a request body with a format of JSON, and it's just a JSON object that contains a logo with a string value. If we send that request, you'll notice we get a 500 error response, which means our API code is broken. So what's going on here? It's telling us we have a runtime error because we can't destructure the property Mogo from the request body. The reason for that is that Express does not parse JSON in the body by default.

Not everybody uses Express to build a JSON API, so that's not the default behavior. What we need to do here is set up middleware that tells Express to parse JSON before the actual data It's the function that we're using here to handle the request. When you hear the term middleware, think of shared code that runs before every endpoint callback Mac, that you've defined. Very common middleware is built into Express itself. We can refactor our code here a little bit to make a variable for Express, And then we can call app dot use to apply middleware.

In this case, the middleware we want to apply is the express dotjsonmiddleware. Now every request that comes in will first go through this express JSON middleware, which will convert the body to JSON, therefore, making it available both in our post callback. Let's go ahead and save, restart our server, and then go back to Insomnia. And if we send the same exact request, you'll notice this time, We get back a successful response. In addition, if we make the logo an empty string and try to send the same request, We get a 4 18 response along with a message that we need a logo.

Congratulations. You just built a restful API from scratch with no JS and express. But before we wrap up the video, there's one more thing you should definitely know about when it comes to restful APIs. And that is the open API my spec, which provides a standard way to describe an API in YAML. It originally came about in something called the swagger framework, and what it allows you to do is describe your API in a way that can be understood by both humans and machines.

And if you're building a serious API, you get all kinds of awesome benefits in the process. Your API will be fully documented, making it much easier for the end user to work with. And because it follows a standard format, you can actually just automatically generate all of your client side or server side code. What I'm using right now is a free tool called Swagger Hub, and I can come up here and hit the export button to automatically generate a bunch of boilerplate code. Now I'm usually not a huge fan of code generators, but there's a more powerful reason to use OpenAPI.

When you describe your API With the open API spec, you can then upload the configuration to tools like API Gateway on AWS or Google Cloud, where it can be secured, monitored, and connected to back end infrastructure. Let me know if you wanna see a full tutorial on that topic, but I'm gonna go ahead and wrap things up there. And if you want access to even More advanced content, consider becoming a pro member at FireShip IO. Thanks for watching, and I will see you in the next one.
An application programming interface or API is a way for 2 computers to talk to each other. Using an API is just like using a website in your browser, but instead of clicking buttons and filling out forms, you write code to explicitly request data from a server. For example, we could visit the NASA a website to look at asteroids, or we could use their rest API to request the raw JSON data that is shown on the screen.
programming
infrastructure
networking
software
Now most APIs in The world are restful, which means they follow a set of rules or constraints known as representational state transfer, which has been the de facto standard for API development since the early 2000.
A restful API organizes data entities or resources into a bunch of unique URLs. Well, technically not URLs, but u r i's or uniform resource identifiers that differentiate different types of data resources on a server. A client can get data about a resource by making a request to that endpoint over HTTP.
databases
The request Message has a very specific format. Most importantly, the start line contains the URI that you wish to access, which is preceded by an HTTP verb or request method, which signal your intent with the resource. A git request means you just want to read the data, while post means you want to create a new resource. Patch is for Updates, delete is for removing data, along with a few other methods beyond those. Below the start line, we have headers, which contain metadata about the request. The accept header can tell the server you want the data in a specific format, or the authorization header can be used to tell the server that you're actually allowed to make that request. Then following the headers, we have the body, which contains a custom payload of data. The server will receive the request message, then execute some code, usually to read from a database, that can then be formatted into a response message. The top of the message contains a status code to tell the client what happened to their request. Codes at the 200 level mean that things went well. At the 400 level, it means something was wrong with your request. And at the 500 level, it means that the server failed. After for the status code, we then have the response headers, which contain information about the server. That's followed by the response body, which contains the data payload and is usually formatted in JSON when talking about APIs. Now an important part of this architecture is that it's stateless, which means that the 2 parties don't need to store any information about each other, and every request response cycle is independent from all other communication. And this leads to well behaved web applications that are predictable and reliable. This has been restful APIs in 100 seconds. If you enjoyed it, leave a comment below. Then next week, I'll pick out the best one to win this free t shirt. And now it's time to go beyond 100 seconds to build a restful API from scratch. The most popular framework for building restful APIs in Node is Express JS. It's been around forever and it's very minimal and easy to learn if you know a little bit of JavaScript.
Over the next few minutes, we'll use Express to build our own restful API from scratch. You'll learn how to create different endpoints for your API. We'll also look at slightly more advanced concepts like middleware and tools in the cloud for deploying your API like API gateways. To get started, you'll want to open up Versus code to an empty directory. You'll need to have Node. Js installed, and I'm using version 12 for this video.
software development
software
To start a new Node project, let's run npm init y from the command line. This will create a package JSON and give us a context for installing packages that we can use in Node like Express. Let's go ahead and install Express using npm install. You'll notice that adds express to our dependencies in the package JSON file. From there, we'll need a file to write our code in, so let's create an index dotjs file.
At the top of that file, we'll declare a variable for app, which represents the actual API that we're building. And its value is an import of the express package, which itself is a function, so we'll add parenthesis after it to initialize it. Now at this point, our API has in to find any endpoint, but let's go ahead and run it anyway.
programming
The way you fire up your API on the server is by calling app dot listen. That tells it to listen on a specific port, which we've defined as its own separate variable as 8080. Then as an optional second argument To listen, we can fire a callback to let us know when the API is ready, and we'll just have it console log the main URL. We can now run the API by going to the terminal and running node period to run that index dot JS file. And it should console log, it's alive on local host 8080. If we paste the URL into the browser, you can see we get a message of cannot get. That's because we don't have any API endpoints set up yet, but Express is still responding with an error message.
In fact, you can open up the network tab in Chrome. If we look closely, we can see that our server responded with a 404 status code, meaning that page was not found. At this point, we know our API is working, but debugging it in the browser is usually not the best option.
internet
networking
There are many different ways we can access our API.
We could use curl from the command line, we can install a Versus Code extension, or we could use a REST client like Insomnia or Postman. I'm going to be using Insomnia throughout the rest of this video because it provides a really nice way to format your requests and also via history of all your interactions. From Insomnia, We can create a new request, then simply paste in our URL. We can easily change the HTTP verb from the drop down menu here, Click Send and then get the response in a nicely formatted developer friendly way.
video gaming
software
multimedia
streaming
We can even see the timeline here with our request in yellow and the response in green. But now we need to get back to our JavaScript and add an endpoint to the API. We can do that by chaining an HTTP verb to the app instance. If you type a period after app, you'll get IntelliSense on a bunch of different methods that live on this object, and you'll notice methods for git, post, patch, etcetera, which represent different HTTP verbs. If we want to add a git endpoint to the t shirt URI, we can do that by passing /tshirt as its first argument. That'll automatically set up our server with that endpoint, then it's our job to handle a request to it, which we do by passing a callback function as the second argument. Whenever a client or end user requests that URL, it will fire this callback function to handle the request. The function itself provides access to 2 different objects, the request object and the response object.
The request is the incoming data, while the response is the data we want to send back to the client. The most important thing it does is allow us to send a response back to the client. That response can have a status code like 200 for an okay response, then we can send a data payload along with it.
data
If we pass a JavaScript object as the argument, then it will send that data back as JSON by default. Let's go ahead and save the file, then restart server from the terminal. From Insomnia, we can then make a get request to local host 8080/t shirt. When we do that, We get a JSON object back as the response body with a status code of 200. That's pretty cool. But now let's go back to our code and add a second endpoint, This time, a post endpoint followed by a slash and a dynamic URL parameter that represents the ID of that t shirt.
There might be millions of different t shirts on this API and a dynamic URL allows us to handle all of them from a single function. When dealing with a post request, It means that the user is trying to create new data on the server or create a new t shirt in this case.
twitter
First, we need the ID, which we can get from the URL, and its value is made available to us on the request parameters object. 2nd, we also need a logo for the t shirt, But the logo is contained in the request body, which if you remember from earlier, is a custom data payload contained in the incoming request.
In other words, the request Object and Express allows us to access information from the request message, like the URL parameters, the body, the headers, etcetera. And now that we have that information, we could use it to save a new record to the database or something along those lines. That's beyond the scope of this video. What we'll do for Right now is check to make sure that we have a logo in the request body, and if we don't, then we'll send an error response with a 4 18 status code and an error message that we need a logo.
databases
data management
multimedia
data
But assuming we do have a valid logo, we can just send a response with a t shirt that contains that logo and ID. Now let's go back to Insomnia, and we'll make a post request to that t shirt endpoint followed by a unique ID that can be whatever you want. Then in the body section, we'll go ahead and add a request body with a format of JSON, and it's just a JSON object that contains a logo with a string value. If we send that request, you'll notice we get a 500 error response, which means our API code is broken. So what's going on here? It's telling us we have a runtime error because we can't destructure the property Mogo from the request body. The reason for that is that Express does not parse JSON in the body by default. Not everybody uses Express to build a JSON API, so that's not the default behavior. What we need to do here is set up middleware that tells Express to parse JSON before the actual data It's the function that we're using here to handle the request.
When you hear the term middleware, think of shared code that runs before every endpoint callback Mac, that you've defined. Very common middleware is built into Express itself. We can refactor our code here a little bit to make a variable for Express, And then we can call app dot use to apply middleware.
software
In this case, the middleware we want to apply is the express dotjsonmiddleware. Now every request that comes in will first go through this express JSON middleware, which will convert the body to JSON, therefore, making it available both in our post callback. Let's go ahead and save, restart our server, and then go back to Insomnia. And if we send the same exact request, you'll notice this time, We get back a successful response. In addition, if we make the logo an empty string and try to send the same request, We get a 4 18 response along with a message that we need a logo. Congratulations. You just built a restful API from scratch with no JS and express. But before we wrap up the video, there's one more thing you should definitely know about when it comes to restful APIs. And that is the open API my spec, which provides a standard way to describe an API in YAML. It originally came about in something called the swagger framework, and what it allows you to do is describe your API in a way that can be understood by both humans and machines.
And if you're building a serious API, you get all kinds of awesome benefits in the process. Your API will be fully documented, making it much easier for the end user to work with. And because it follows a standard format, you can actually just automatically generate all of your client side or server side code. What I'm using right now is a free tool called Swagger Hub, and I can come up here and hit the export button to automatically generate a bunch of boilerplate code. Now I'm usually not a huge fan of code generators, but there's a more powerful reason to use OpenAPI. When you describe your API With the open API spec, you can then upload the configuration to tools like API Gateway on AWS or Google Cloud, where it can be secured, monitored, and connected to back end infrastructure.
infrastructure
programming
software
software development
Let me know if you wanna see a full tutorial on that topic, but I'm gonna go ahead and wrap things up there. And if you want access to even More advanced content, consider becoming a pro member at FireShip IO. Thanks for watching, and I will see you in the next one.
An application programming interface or API is a way for 2 computers to talk to each other. Using an API is just like using a website in your browser, but instead of clicking buttons and filling out forms, you write code to explicitly request data from a server. For example, we could visit the NASA a website to look at asteroids, or we could use their rest API to request the raw JSON data that is shown on the screen. Now most APIs in The world are restful, which means they follow a set of rules or constraints known as representational state transfer, which has been the de facto standard for API development since the early 2000. A restful API organizes data entities or resources into a bunch of unique URLs. Well, technically not URLs, but u r i's or uniform resource identifiers that differentiate different types of data resources on a server. A client can get data about a resource by making a request to that endpoint over HTTP. The request Message has a very specific format. Most importantly, the start line contains the URI that you wish to access, which is preceded by an HTTP verb or request method, which signal your intent with the resource. A git request means you just want to read the data, while post means you want to create a new resource. Patch is for Updates, delete is for removing data, along with a few other methods beyond those. Below the start line, we have headers, which contain metadata about the request. The accept header can tell the server you want the data in a specific format, or the authorization header can be used to tell the server that you're actually allowed to make that request. Then following the headers, we have the body, which contains a custom payload of data. The server will receive the request message, then execute some code, usually to read from a database, that can then be formatted into a response message. The top of the message contains a status code to tell the client what happened to their request. Codes at the 200 level mean that things went well. At the 400 level, it means something was wrong with your request. And at the 500 level, it means that the server failed. After for the status code, we then have the response headers, which contain information about the server. That's followed by the response body, which contains the data payload and is usually formatted in JSON when talking about APIs. Now an important part of this architecture is that it's stateless, which means that the 2 parties don't need to store any information about each other, and every request response cycle is independent from all other communication. And this leads to well behaved web applications that are predictable and reliable. This has been restful APIs in 100 seconds. If you enjoyed it, leave a comment below. Then next week, I'll pick out the best one to win this free t shirt. And now it's time to go beyond 100 seconds to build a restful API from scratch. The most popular framework for building restful APIs in Node is Express JS. It's been around forever and it's very minimal and easy to learn if you know a little bit of JavaScript. Over the next few minutes, we'll use Express to build our own restful API from scratch. You'll learn how to create different endpoints for your API. We'll also look at slightly more advanced concepts like middleware and tools in the cloud for deploying your API like API gateways. To get started, you'll want to open up Versus code to an empty directory. You'll need to have Node. Js installed, and I'm using version 12 for this video. To start a new Node project, let's run npm init y from the command line. This will create a package JSON and give us a context for installing packages that we can use in Node like Express. Let's go ahead and install Express using npm install. You'll notice that adds express to our dependencies in the package JSON file. From there, we'll need a file to write our code in, so let's create an index dotjs file. At the top of that file, we'll declare a variable for app, which represents the actual API that we're building. And its value is an import of the express package, which itself is a function, so we'll add parenthesis after it to initialize it. Now at this point, our API has in to find any endpoint, but let's go ahead and run it anyway. The way you fire up your API on the server is by calling app dot listen. That tells it to listen on a specific port, which we've defined as its own separate variable as 8080. Then as an optional second argument To listen, we can fire a callback to let us know when the API is ready, and we'll just have it console log the main URL. We can now run the API by going to the terminal and running node period to run that index dot JS file. And it should console log, it's alive on local host 8080. If we paste the URL into the browser, you can see we get a message of cannot get. That's because we don't have any API endpoints set up yet, but Express is still responding with an error message. In fact, you can open up the network tab in Chrome. If we look closely, we can see that our server responded with a 404 status code, meaning that page was not found. At this point, we know our API is working, but debugging it in the browser is usually not the best option. There are many different ways we can access our API. We could use curl from the command line, we can install a Versus Code extension, or we could use a REST client like Insomnia or Postman. I'm going to be using Insomnia throughout the rest of this video because it provides a really nice way to format your requests and also via history of all your interactions. From Insomnia, We can create a new request, then simply paste in our URL. We can easily change the HTTP verb from the drop down menu here, Click Send and then get the response in a nicely formatted developer friendly way. We can even see the timeline here with our request in yellow and the response in green. But now we need to get back to our JavaScript and add an endpoint to the API. We can do that by chaining an HTTP verb to the app instance. If you type a period after app, you'll get IntelliSense on a bunch of different methods that live on this object, and you'll notice methods for git, post, patch, etcetera, which represent different HTTP verbs. If we want to add a git endpoint to the t shirt URI, we can do that by passing /tshirt as its first argument. That'll automatically set up our server with that endpoint, then it's our job to handle a request to it, which we do by passing a callback function as the second argument. Whenever a client or end user requests that URL, it will fire this callback function to handle the request. The function itself provides access to 2 different objects, the request object and the response object. The request is the incoming data, while the response is the data we want to send back to the client. The most important thing it does is allow us to send a response back to the client. That response can have a status code like 200 for an okay response, then we can send a data payload along with it. If we pass a JavaScript object as the argument, then it will send that data back as JSON by default. Let's go ahead and save the file, then restart server from the terminal. From Insomnia, we can then make a get request to local host 8080/t shirt. When we do that, We get a JSON object back as the response body with a status code of 200. That's pretty cool. But now let's go back to our code and add a second endpoint, This time, a post endpoint followed by a slash and a dynamic URL parameter that represents the ID of that t shirt. There might be millions of different t shirts on this API and a dynamic URL allows us to handle all of them from a single function. When dealing with a post request, It means that the user is trying to create new data on the server or create a new t shirt in this case. First, we need the ID, which we can get from the URL, and its value is made available to us on the request parameters object. 2nd, we also need a logo for the t shirt, But the logo is contained in the request body, which if you remember from earlier, is a custom data payload contained in the incoming request. In other words, the request Object and Express allows us to access information from the request message, like the URL parameters, the body, the headers, etcetera. And now that we have that information, we could use it to save a new record to the database or something along those lines. That's beyond the scope of this video. What we'll do for Right now is check to make sure that we have a logo in the request body, and if we don't, then we'll send an error response with a 4 18 status code and an error message that we need a logo. But assuming we do have a valid logo, we can just send a response with a t shirt that contains that logo and ID. Now let's go back to Insomnia, and we'll make a post request to that t shirt endpoint followed by a unique ID that can be whatever you want. Then in the body section, we'll go ahead and add a request body with a format of JSON, and it's just a JSON object that contains a logo with a string value. If we send that request, you'll notice we get a 500 error response, which means our API code is broken. So what's going on here? It's telling us we have a runtime error because we can't destructure the property Mogo from the request body. The reason for that is that Express does not parse JSON in the body by default. Not everybody uses Express to build a JSON API, so that's not the default behavior. What we need to do here is set up middleware that tells Express to parse JSON before the actual data It's the function that we're using here to handle the request. When you hear the term middleware, think of shared code that runs before every endpoint callback Mac, that you've defined. Very common middleware is built into Express itself. We can refactor our code here a little bit to make a variable for Express, And then we can call app dot use to apply middleware. In this case, the middleware we want to apply is the express dotjsonmiddleware. Now every request that comes in will first go through this express JSON middleware, which will convert the body to JSON, therefore, making it available both in our post callback. Let's go ahead and save, restart our server, and then go back to Insomnia. And if we send the same exact request, you'll notice this time, We get back a successful response. In addition, if we make the logo an empty string and try to send the same request, We get a 4 18 response along with a message that we need a logo. Congratulations. You just built a restful API from scratch with no JS and express. But before we wrap up the video, there's one more thing you should definitely know about when it comes to restful APIs. And that is the open API my spec, which provides a standard way to describe an API in YAML. It originally came about in something called the swagger framework, and what it allows you to do is describe your API in a way that can be understood by both humans and machines. And if you're building a serious API, you get all kinds of awesome benefits in the process. Your API will be fully documented, making it much easier for the end user to work with. And because it follows a standard format, you can actually just automatically generate all of your client side or server side code. What I'm using right now is a free tool called Swagger Hub, and I can come up here and hit the export button to automatically generate a bunch of boilerplate code. Now I'm usually not a huge fan of code generators, but there's a more powerful reason to use OpenAPI. When you describe your API With the open API spec, you can then upload the configuration to tools like API Gateway on AWS or Google Cloud, where it can be secured, monitored, and connected to back end infrastructure. Let me know if you wanna see a full tutorial on that topic, but I'm gonna go ahead and wrap things up there. And if you want access to even More advanced content, consider becoming a pro member at FireShip IO. Thanks for watching, and I will see you in the next one.
An
an
application
application
programming
programming
interface
interface
or
or
API
api
is
is
a
a
way
way
for
for
2
2
computers
computers
to
to
talk
talk
to
to
each
each
other.
other
Using
using
an
an
API
api
is
is
just
just
like
like
using
using
a
a
website
website
in
in
your
your
browser,
browser
but
but
instead
instead
of
of
clicking
clicking
buttons
buttons
and
and
filling
filling
out
out
forms,
forms
you
you
write
write
code
code
to
to
explicitly
explicitly
request
request
data
data
from
from
a
a
server.
server
For
for
example,
example
we
we
could
could
visit
visit
the
the
NASA
nasa
a
a
website
website
to
to
look
look
at
at
asteroids,
asteroids
or
or
we
we
could
could
use
use
their
their
rest
rest
API
api
to
to
request
request
the
the
raw
raw
JSON
json
data
data
that
that
is
is
shown
shown
on
on
the
the
screen.
screen
Now
now
most
most
APIs
apis
in
in
The
the
world
world
are
are
restful,
restful
which
which
means
means
they
they
follow
follow
a
a
set
set
of
of
rules
rules
or
or
constraints
constraints
known
known
as
as
representational
representational
state
state
transfer,
transfer
which
which
has
has
been
been
the
the
de
de
facto
facto
standard
standard
for
for
API
api
development
development
since
since
the
the
early
early
2000.
2000
A
a
restful
restful
API
api
organizes
organizes
data
data
entities
entities
or
or
resources
resources
into
into
a
a
bunch
bunch
of
of
unique
unique
URLs.
urls
Well,
well
technically
technically
not
not
URLs,
urls
but
but
u
u
r
r
i's
i's
or
or
uniform
uniform
resource
resource
identifiers
identifiers
that
that
differentiate
differentiate
different
different
types
types
of
of
data
data
resources
resources
on
on
a
a
server.
server
A
a
client
client
can
can
get
get
data
data
about
about
a
a
resource
resource
by
by
making
making
a
a
request
request
to
to
that
that
endpoint
endpoint
over
over
HTTP.
http
The
the
request
request
Message
message
has
has
a
a
very
very
specific
specific
format.
format
Most
most
importantly,
importantly
the
the
start
start
line
line
contains
contains
the
the
URI
uri
that
that
you
you
wish
wish
to
to
access,
access
which
which
is
is
preceded
preceded
by
by
an
an
HTTP
http
verb
verb
or
or
request
request
method,
method
which
which
signal
signal
your
your
intent
intent
with
with
the
the
resource.
resource
A
a
git
git
request
request
means
means
you
you
just
just
want
want
to
to
read
read
the
the
data,
data
while
while
post
post
means
means
you
you
want
want
to
to
create
create
a
a
new
new
resource.
resource
Patch
patch
is
is
for
for
Updates,
updates
delete
delete
is
is
for
for
removing
removing
data,
data
along
along
with
with
a
a
few
few
other
other
methods
methods
beyond
beyond
those.
those
Below
below
the
the
start
start
line,
line
we
we
have
have
headers,
headers
which
which
contain
contain
metadata
metadata
about
about
the
the
request.
request
The
the
accept
accept
header
header
can
can
tell
tell
the
the
server
server
you
you
want
want
the
the
data
data
in
in
a
a
specific
specific
format,
format
or
or
the
the
authorization
authorization
header
header
can
can
be
be
used
used
to
to
tell
tell
the
the
server
server
that
that
you're
you're
actually
actually
allowed
allowed
to
to
make
make
that
that
request.
request
Then
then
following
following
the
the
headers,
headers
we
we
have
have
the
the
body,
body
which
which
contains
contains
a
a
custom
custom
payload
payload
of
of
data.
data
The
the
server
server
will
will
receive
receive
the
the
request
request
message,
message
then
then
execute
execute
some
some
code,
code
usually
usually
to
to
read
read
from
from
a
a
database,
database
that
that
can
can
then
then
be
be
formatted
formatted
into
into
a
a
response
response
message.
message
The
the
top
top
of
of
the
the
message
message
contains
contains
a
a
status
status
code
code
to
to
tell
tell
the
the
client
client
what
what
happened
happened
to
to
their
their
request.
request
Codes
codes
at
at
the
the
200
200
level
level
mean
mean
that
that
things
things
went
went
well.
well
At
at
the
the
400
400
level,
level
it
it
means
means
something
something
was
was
wrong
wrong
with
with
your
your
request.
request
And
and
at
at
the
the
500
500
level,
level
it
it
means
means
that
that
the
the
server
server
failed.
failed
After
after
for
for
the
the
status
status
code,
code
we
we
then
then
have
have
the
the
response
response
headers,
headers
which
which
contain
contain
information
information
about
about
the
the
server.
server
That's
that's
followed
followed
by
by
the
the
response
response
body,
body
which
which
contains
contains
the
the
data
data
payload
payload
and
and
is
is
usually
usually
formatted
formatted
in
in
JSON
json
when
when
talking
talking
about
about
APIs.
apis
Now
now
an
an
important
important
part
part
of
of
this
this
architecture
architecture
is
is
that
that
it's
it's
stateless,
stateless
which
which
means
means
that
that
the
the
2
2
parties
parties
don't
don't
need
need
to
to
store
store
any
any
information
information
about
about
each
each
other,
other
and
and
every
every
request
request
response
response
cycle
cycle
is
is
independent
independent
from
from
all
all
other
other
communication.
communication
And
and
this
this
leads
leads
to
to
well
well
behaved
behaved
web
web
applications
applications
that
that
are
are
predictable
predictable
and
and
reliable.
reliable
This
this
has
has
been
been
restful
restful
APIs
apis
in
in
100
100
seconds.
seconds
If
if
you
you
enjoyed
enjoyed
it,
it
leave
leave
a
a
comment
comment
below.
below
Then
then
next
next
week,
week
I'll
i'll
pick
pick
out
out
the
the
best
best
one
one
to
to
win
win
this
this
free
free
t
t
shirt.
shirt
And
and
now
now
it's
it's
time
time
to
to
go
go
beyond
beyond
100
100
seconds
seconds
to
to
build
build
a
a
restful
restful
API
api
from
from
scratch.
scratch
The
the
most
most
popular
popular
framework
framework
for
for
building
building
restful
restful
APIs
apis
in
in
Node
node
is
is
Express
express
JS.
js
It's
it's
been
been
around
around
forever
forever
and
and
it's
it's
very
very
minimal
minimal
and
and
easy
easy
to
to
learn
learn
if
if
you
you
know
know
a
a
little
little
bit
bit
of
of
JavaScript.
javascript
Over
over
the
the
next
next
few
few
minutes,
minutes
we'll
we'll
use
use
Express
express
to
to
build
build
our
our
own
own
restful
restful
API
api
from
from
scratch.
scratch
You'll
you'll
learn
learn
how
how
to
to
create
create
different
different
endpoints
endpoints
for
for
your
your
API.
api
We'll
we'll
also
also
look
look
at
at
slightly
slightly
more
more
advanced
advanced
concepts
concepts
like
like
middleware
middleware
and
and
tools
tools
in
in
the
the
cloud
cloud
for
for
deploying
deploying
your
your
API
api
like
like
API
api
gateways.
gateways
To
to
get
get
started,
started
you'll
you'll
want
want
to
to
open
open
up
up
Versus
versus
code
code
to
to
an
an
empty
empty
directory.
directory
You'll
you'll
need
need
to
to
have
have
Node.
node
Js
js
installed,
installed
and
and
I'm
i'm
using
using
version
version
12
12
for
for
this
this
video.
video
To
to
start
start
a
a
new
new
Node
node
project,
project
let's
let's
run
run
npm
npm
init
init
y
y
from
from
the
the
command
command
line.
line
This
this
will
will
create
create
a
a
package
package
JSON
json
and
and
give
give
us
us
a
a
context
context
for
for
installing
installing
packages
packages
that
that
we
we
can
can
use
use
in
in
Node
node
like
like
Express.
express
Let's
let's
go
go
ahead
ahead
and
and
install
install
Express
express
using
using
npm
npm
install.
install
You'll
you'll
notice
notice
that
that
adds
adds
express
express
to
to
our
our
dependencies
dependencies
in
in
the
the
package
package
JSON
json
file.
file
From
from
there,
there
we'll
we'll
need
need
a
a
file
file
to
to
write
write
our
our
code
code
in,
in
so
so
let's
let's
create
create
an
an
index
index
dotjs
dotjs
file.
file
At
at
the
the
top
top
of
of
that
that
file,
file
we'll
we'll
declare
declare
a
a
variable
variable
for
for
app,
app
which
which
represents
represents
the
the
actual
actual
API
api
that
that
we're
we're
building.
building
And
and
its
its
value
value
is
is
an
an
import
import
of
of
the
the
express
express
package,
package
which
which
itself
itself
is
is
a
a
function,
function
so
so
we'll
we'll
add
add
parenthesis
parenthesis
after
after
it
it
to
to
initialize
initialize
it.
it
Now
now
at
at
this
this
point,
point
our
our
API
api
has
has
in
in
to
to
find
find
any
any
endpoint,
endpoint
but
but
let's
let's
go
go
ahead
ahead
and
and
run
run
it
it
anyway.
anyway
The
the
way
way
you
you
fire
fire
up
up
your
your
API
api
on
on
the
the
server
server
is
is
by
by
calling
calling
app
app
dot
dot
listen.
listen
That
that
tells
tells
it
it
to
to
listen
listen
on
on
a
a
specific
specific
port,
port
which
which
we've
we've
defined
defined
as
as
its
its
own
own
separate
separate
variable
variable
as
as
8080.
8080
Then
then
as
as
an
an
optional
optional
second
second
argument
argument
To
to
listen,
listen
we
we
can
can
fire
fire
a
a
callback
callback
to
to
let
let
us
us
know
know
when
when
the
the
API
api
is
is
ready,
ready
and
and
we'll
we'll
just
just
have
have
it
it
console
console
log
log
the
the
main
main
URL.
url
We
we
can
can
now
now
run
run
the
the
API
api
by
by
going
going
to
to
the
the
terminal
terminal
and
and
running
running
node
node
period
period
to
to
run
run
that
that
index
index
dot
dot
JS
js
file.
file
And
and
it
it
should
should
console
console
log,
log
it's
it's
alive
alive
on
on
local
local
host
host
8080.
8080
If
if
we
we
paste
paste
the
the
URL
url
into
into
the
the
browser,
browser
you
you
can
can
see
see
we
we
get
get
a
a
message
message
of
of
cannot
cannot
get.
get
That's
that's
because
because
we
we
don't
don't
have
have
any
any
API
api
endpoints
endpoints
set
set
up
up
yet,
yet
but
but
Express
express
is
is
still
still
responding
responding
with
with
an
an
error
error
message.
message
In
in
fact,
fact
you
you
can
can
open
open
up
up
the
the
network
network
tab
tab
in
in
Chrome.
chrome
If
if
we
we
look
look
closely,
closely
we
we
can
can
see
see
that
that
our
our
server
server
responded
responded
with
with
a
a
404
404
status
status
code,
code
meaning
meaning
that
that
page
page
was
was
not
not
found.
found
At
at
this
this
point,
point
we
we
know
know
our
our
API
api
is
is
working,
working
but
but
debugging
debugging
it
it
in
in
the
the
browser
browser
is
is
usually
usually
not
not
the
the
best
best
option.
option
There
there
are
are
many
many
different
different
ways
ways
we
we
can
can
access
access
our
our
API.
api
We
we
could
could
use
use
curl
curl
from
from
the
the
command
command
line,
line
we
we
can
can
install
install
a
a
Versus
versus
Code
code
extension,
extension
or
or
we
we
could
could
use
use
a
a
REST
rest
client
client
like
like
Insomnia
insomnia
or
or
Postman.
postman
I'm
i'm
going
going
to
to
be
be
using
using
Insomnia
insomnia
throughout
throughout
the
the
rest
rest
of
of
this
this
video
video
because
because
it
it
provides
provides
a
a
really
really
nice
nice
way
way
to
to
format
format
your
your
requests
requests
and
and
also
also
via
via
history
history
of
of
all
all
your
your
interactions.
interactions
From
from
Insomnia,
insomnia
We
we
can
can
create
create
a
a
new
new
request,
request
then
then
simply
simply
paste
paste
in
in
our
our
URL.
url
We
we
can
can
easily
easily
change
change
the
the
HTTP
http
verb
verb
from
from
the
the
drop
drop
down
down
menu
menu
here,
here
Click
click
Send
send
and
and
then
then
get
get
the
the
response
response
in
in
a
a
nicely
nicely
formatted
formatted
developer
developer
friendly
friendly
way.
way
We
we
can
can
even
even
see
see
the
the
timeline
timeline
here
here
with
with
our
our
request
request
in
in
yellow
yellow
and
and
the
the
response
response
in
in
green.
green
But
but
now
now
we
we
need
need
to
to
get
get
back
back
to
to
our
our
JavaScript
javascript
and
and
add
add
an
an
endpoint
endpoint
to
to
the
the
API.
api
We
we
can
can
do
do
that
that
by
by
chaining
chaining
an
an
HTTP
http
verb
verb
to
to
the
the
app
app
instance.
instance
If
if
you
you
type
type
a
a
period
period
after
after
app,
app
you'll
you'll
get
get
IntelliSense
intellisense
on
on
a
a
bunch
bunch
of
of
different
different
methods
methods
that
that
live
live
on
on
this
this
object,
object
and
and
you'll
you'll
notice
notice
methods
methods
for
for
git,
git
post,
post
patch,
patch
etcetera,
etcetera
which
which
represent
represent
different
different
HTTP
http
verbs.
verbs
If
if
we
we
want
want
to
to
add
add
a
a
git
git
endpoint
endpoint
to
to
the
the
t
t
shirt
shirt
URI,
uri
we
we
can
can
do
do
that
that
by
by
passing
passing
/tshirt
/tshirt
as
as
its
its
first
first
argument.
argument
That'll
that'll
automatically
automatically
set
set
up
up
our
our
server
server
with
with
that
that
endpoint,
endpoint
then
then
it's
it's
our
our
job
job
to
to
handle
handle
a
a
request
request
to
to
it,
it
which
which
we
we
do
do
by
by
passing
passing
a
a
callback
callback
function
function
as
as
the
the
second
second
argument.
argument
Whenever
whenever
a
a
client
client
or
or
end
end
user
user
requests
requests
that
that
URL,
url
it
it
will
will
fire
fire
this
this
callback
callback
function
function
to
to
handle
handle
the
the
request.
request
The
the
function
function
itself
itself
provides
provides
access
access
to
to
2
2
different
different
objects,
objects
the
the
request
request
object
object
and
and
the
the
response
response
object.
object
The
the
request
request
is
is
the
the
incoming
incoming
data,
data
while
while
the
the
response
response
is
is
the
the
data
data
we
we
want
want
to
to
send
send
back
back
to
to
the
the
client.
client
The
the
most
most
important
important
thing
thing
it
it
does
does
is
is
allow
allow
us
us
to
to
send
send
a
a
response
response
back
back
to
to
the
the
client.
client
That
that
response
response
can
can
have
have
a
a
status
status
code
code
like
like
200
200
for
for
an
an
okay
okay
response,
response
then
then
we
we
can
can
send
send
a
a
data
data
payload
payload
along
along
with
with
it.
it
If
if
we
we
pass
pass
a
a
JavaScript
javascript
object
object
as
as
the
the
argument,
argument
then
then
it
it
will
will
send
send
that
that
data
data
back
back
as
as
JSON
json
by
by
default.
default
Let's
let's
go
go
ahead
ahead
and
and
save
save
the
the
file,
file
then
then
restart
restart
server
server
from
from
the
the
terminal.
terminal
From
from
Insomnia,
insomnia
we
we
can
can
then
then
make
make
a
a
get
get
request
request
to
to
local
local
host
host
8080/t
8080/t
shirt.
shirt
When
when
we
we
do
do
that,
that
We
we
get
get
a
a
JSON
json
object
object
back
back
as
as
the
the
response
response
body
body
with
with
a
a
status
status
code
code
of
of
200.
200
That's
that's
pretty
pretty
cool.
cool
But
but
now
now
let's
let's
go
go
back
back
to
to
our
our
code
code
and
and
add
add
a
a
second
second
endpoint,
endpoint
This
this
time,
time
a
a
post
post
endpoint
endpoint
followed
followed
by
by
a
a
slash
slash
and
and
a
a
dynamic
dynamic
URL
url
parameter
parameter
that
that
represents
represents
the
the
ID
id
of
of
that
that
t
t
shirt.
shirt
There
there
might
might
be
be
millions
millions
of
of
different
different
t
t
shirts
shirts
on
on
this
this
API
api
and
and
a
a
dynamic
dynamic
URL
url
allows
allows
us
us
to
to
handle
handle
all
all
of
of
them
them
from
from
a
a
single
single
function.
function
When
when
dealing
dealing
with
with
a
a
post
post
request,
request
It
it
means
means
that
that
the
the
user
user
is
is
trying
trying
to
to
create
create
new
new
data
data
on
on
the
the
server
server
or
or
create
create
a
a
new
new
t
t
shirt
shirt
in
in
this
this
case.
case
First,
first
we
we
need
need
the
the
ID,
id
which
which
we
we
can
can
get
get
from
from
the
the
URL,
url
and
and
its
its
value
value
is
is
made
made
available
available
to
to
us
us
on
on
the
the
request
request
parameters
parameters
object.
object
2nd,
2nd
we
we
also
also
need
need
a
a
logo
logo
for
for
the
the
t
t
shirt,
shirt
But
but
the
the
logo
logo
is
is
contained
contained
in
in
the
the
request
request
body,
body
which
which
if
if
you
you
remember
remember
from
from
earlier,
earlier
is
is
a
a
custom
custom
data
data
payload
payload
contained
contained
in
in
the
the
incoming
incoming
request.
request
In
in
other
other
words,
words
the
the
request
request
Object
object
and
and
Express
express
allows
allows
us
us
to
to
access
access
information
information
from
from
the
the
request
request
message,
message
like
like
the
the
URL
url
parameters,
parameters
the
the
body,
body
the
the
headers,
headers
etcetera.
etcetera
And
and
now
now
that
that
we
we
have
have
that
that
information,
information
we
we
could
could
use
use
it
it
to
to
save
save
a
a
new
new
record
record
to
to
the
the
database
database
or
or
something
something
along
along
those
those
lines.
lines
That's
that's
beyond
beyond
the
the
scope
scope
of
of
this
this
video.
video
What
what
we'll
we'll
do
do
for
for
Right
right
now
now
is
is
check
check
to
to
make
make
sure
sure
that
that
we
we
have
have
a
a
logo
logo
in
in
the
the
request
request
body,
body
and
and
if
if
we
we
don't,
don't
then
then
we'll
we'll
send
send
an
an
error
error
response
response
with
with
a
a
4
4
18
18
status
status
code
code
and
and
an
an
error
error
message
message
that
that
we
we
need
need
a
a
logo.
logo
But
but
assuming
assuming
we
we
do
do
have
have
a
a
valid
valid
logo,
logo
we
we
can
can
just
just
send
send
a
a
response
response
with
with
a
a
t
t
shirt
shirt
that
that
contains
contains
that
that
logo
logo
and
and
ID.
id
Now
now
let's
let's
go
go
back
back
to
to
Insomnia,
insomnia
and
and
we'll
we'll
make
make
a
a
post
post
request
request
to
to
that
that
t
t
shirt
shirt
endpoint
endpoint
followed
followed
by
by
a
a
unique
unique
ID
id
that
that
can
can
be
be
whatever
whatever
you
you
want.
want
Then
then
in
in
the
the
body
body
section,
section
we'll
we'll
go
go
ahead
ahead
and
and
add
add
a
a
request
request
body
body
with
with
a
a
format
format
of
of
JSON,
json
and
and
it's
it's
just
just
a
a
JSON
json
object
object
that
that
contains
contains
a
a
logo
logo
with
with
a
a
string
string
value.
value
If
if
we
we
send
send
that
that
request,
request
you'll
you'll
notice
notice
we
we
get
get
a
a
500
500
error
error
response,
response
which
which
means
means
our
our
API
api
code
code
is
is
broken.
broken
So
so
what's
what's
going
going
on
on
here?
here
It's
it's
telling
telling
us
us
we
we
have
have
a
a
runtime
runtime
error
error
because
because
we
we
can't
can't
destructure
destructure
the
the
property
property
Mogo
mogo
from
from
the
the
request
request
body.
body
The
the
reason
reason
for
for
that
that
is
is
that
that
Express
express
does
does
not
not
parse
parse
JSON
json
in
in
the
the
body
body
by
by
default.
default
Not
not
everybody
everybody
uses
uses
Express
express
to
to
build
build
a
a
JSON
json
API,
api
so
so
that's
that's
not
not
the
the
default
default
behavior.
behavior
What
what
we
we
need
need
to
to
do
do
here
here
is
is
set
set
up
up
middleware
middleware
that
that
tells
tells
Express
express
to
to
parse
parse
JSON
json
before
before
the
the
actual
actual
data
data
It's
it's
the
the
function
function
that
that
we're
we're
using
using
here
here
to
to
handle
handle
the
the
request.
request
When
when
you
you
hear
hear
the
the
term
term
middleware,
middleware
think
think
of
of
shared
shared
code
code
that
that
runs
runs
before
before
every
every
endpoint
endpoint
callback
callback
Mac,
mac
that
that
you've
you've
defined.
defined
Very
very
common
common
middleware
middleware
is
is
built
built
into
into
Express
express
itself.
itself
We
we
can
can
refactor
refactor
our
our
code
code
here
here
a
a
little
little
bit
bit
to
to
make
make
a
a
variable
variable
for
for
Express,
express
And
and
then
then
we
we
can
can
call
call
app
app
dot
dot
use
use
to
to
apply
apply
middleware.
middleware
In
in
this
this
case,
case
the
the
middleware
middleware
we
we
want
want
to
to
apply
apply
is
is
the
the
express
express
dotjsonmiddleware.
dotjsonmiddleware
Now
now
every
every
request
request
that
that
comes
comes
in
in
will
will
first
first
go
go
through
through
this
this
express
express
JSON
json
middleware,
middleware
which
which
will
will
convert
convert
the
the
body
body
to
to
JSON,
json
therefore,
therefore
making
making
it
it
available
available
both
both
in
in
our
our
post
post
callback.
callback
Let's
let's
go
go
ahead
ahead
and
and
save,
save
restart
restart
our
our
server,
server
and
and
then
then
go
go
back
back
to
to
Insomnia.
insomnia
And
and
if
if
we
we
send
send
the
the
same
same
exact
exact
request,
request
you'll
you'll
notice
notice
this
this
time,
time
We
we
get
get
back
back
a
a
successful
successful
response.
response
In
in
addition,
addition
if
if
we
we
make
make
the
the
logo
logo
an
an
empty
empty
string
string
and
and
try
try
to
to
send
send
the
the
same
same
request,
request
We
we
get
get
a
a
4
4
18
18
response
response
along
along
with
with
a
a
message
message
that
that
we
we
need
need
a
a
logo.
logo
Congratulations.
congratulations
You
you
just
just
built
built
a
a
restful
restful
API
api
from
from
scratch
scratch
with
with
no
no
JS
js
and
and
express.
express
But
but
before
before
we
we
wrap
wrap
up
up
the
the
video,
video
there's
there's
one
one
more
more
thing
thing
you
you
should
should
definitely
definitely
know
know
about
about
when
when
it
it
comes
comes
to
to
restful
restful
APIs.
apis
And
and
that
that
is
is
the
the
open
open
API
api
my
my
spec,
spec
which
which
provides
provides
a
a
standard
standard
way
way
to
to
describe
describe
an
an
API
api
in
in
YAML.
yaml
It
it
originally
originally
came
came
about
about
in
in
something
something
called
called
the
the
swagger
swagger
framework,
framework
and
and
what
what
it
it
allows
allows
you
you
to
to
do
do
is
is
describe
describe
your
your
API
api
in
in
a
a
way
way
that
that
can
can
be
be
understood
understood
by
by
both
both
humans
humans
and
and
machines.
machines
And
and
if
if
you're
you're
building
building
a
a
serious
serious
API,
api
you
you
get
get
all
all
kinds
kinds
of
of
awesome
awesome
benefits
benefits
in
in
the
the
process.
process
Your
your
API
api
will
will
be
be
fully
fully
documented,
documented
making
making
it
it
much
much
easier
easier
for
for
the
the
end
end
user
user
to
to
work
work
with.
with
And
and
because
because
it
it
follows
follows
a
a
standard
standard
format,
format
you
you
can
can
actually
actually
just
just
automatically
automatically
generate
generate
all
all
of
of
your
your
client
client
side
side
or
or
server
server
side
side
code.
code
What
what
I'm
i'm
using
using
right
right
now
now
is
is
a
a
free
free
tool
tool
called
called
Swagger
swagger
Hub,
hub
and
and
I
i
can
can
come
come
up
up
here
here
and
and
hit
hit
the
the
export
export
button
button
to
to
automatically
automatically
generate
generate
a
a
bunch
bunch
of
of
boilerplate
boilerplate
code.
code
Now
now
I'm
i'm
usually
usually
not
not
a
a
huge
huge
fan
fan
of
of
code
code
generators,
generators
but
but
there's
there's
a
a
more
more
powerful
powerful
reason
reason
to
to
use
use
OpenAPI.
openapi
When
when
you
you
describe
describe
your
your
API
api
With
with
the
the
open
open
API
api
spec,
spec
you
you
can
can
then
then
upload
upload
the
the
configuration
configuration
to
to
tools
tools
like
like
API
api
Gateway
gateway
on
on
AWS
aws
or
or
Google
google
Cloud,
cloud
where
where
it
it
can
can
be
be
secured,
secured
monitored,
monitored
and
and
connected
connected
to
to
back
back
end
end
infrastructure.
infrastructure
Let
let
me
me
know
know
if
if
you
you
wanna
wanna
see
see
a
a
full
full
tutorial
tutorial
on
on
that
that
topic,
topic
but
but
I'm
i'm
gonna
gonna
go
go
ahead
ahead
and
and
wrap
wrap
things
things
up
up
there.
there
And
and
if
if
you
you
want
want
access
access
to
to
even
even
More
more
advanced
advanced
content,
content
consider
consider
becoming
becoming
a
a
pro
pro
member
member
at
at
FireShip
fireship
IO.
io
Thanks
thanks
for
for
watching,
watching
and
and
I
i
will
will
see
see
you
you
in
in
the
the
next
next
one.
one
success
The speakers discuss using restful APIs and Express JS in web applications and creating new APIs from scratch. They stress the importance of creating a logo for requests and discuss setting up post variables and logs. The use of AWS and Azure for code development is emphasized, along with a free tool for developers to use to generate boilerplate code.
RESTful APIs in 100 Seconds // Build an API from Scratch with Node.js Express
An application programming interface or API is a way for 2 computers to talk to each other. Using an API is just like using a website in your browser, but instead of clicking buttons and filling out forms, you write code to explicitly request data from a server. For example, we could visit the NASA a website to look at asteroids, or we could use their rest API to request the raw JSON data that is shown on the screen. Now most APIs in The world are restful, which means they follow a set of rules or constraints known as representational state transfer, which has been the de facto standard for API development since the early 2000. A restful API organizes data entities or resources into a bunch of unique URLs. Well, technically not URLs, but u r i's or uniform resource identifiers that differentiate different types of data resources on a server. A client can get data about a resource by making a request to that endpoint over HTTP. The request Message has a very specific format. Most importantly, the start line contains the URI that you wish to access, which is preceded by an HTTP verb or request method, which signal your intent with the resource. A git request means you just want to read the data, while post means you want to create a new resource. Patch is for Updates, delete is for removing data, along with a few other methods beyond those. Below the start line, we have headers, which contain metadata about the request. The accept header can tell the server you want the data in a specific format, or the authorization header can be used to tell the server that you're actually allowed to make that request. Then following the headers, we have the body, which contains a custom payload of data. The server will receive the request message, then execute some code, usually to read from a database, that can then be formatted into a response message. The top of the message contains a status code to tell the client what happened to their request. Codes at the 200 level mean that things went well. At the 400 level, it means something was wrong with your request. And at the 500 level, it means that the server failed. After for the status code, we then have the response headers, which contain information about the server. That's followed by the response body, which contains the data payload and is usually formatted in JSON when talking about APIs. Now an important part of this architecture is that it's stateless, which means that the 2 parties don't need to store any information about each other, and every request response cycle is independent from all other communication. And this leads to well behaved web applications that are predictable and reliable. This has been restful APIs in 100 seconds. If you enjoyed it, leave a comment below. Then next week, I'll pick out the best one to win this free t shirt. And now it's time to go beyond 100 seconds to build a restful API from scratch. The most popular framework for building restful APIs in Node is Express JS. It's been around forever and it's very minimal and easy to learn if you know a little bit of JavaScript. Over the next few minutes, we'll use Express to build our own restful API from scratch. You'll learn how to create different endpoints for your API. We'll also look at slightly more advanced concepts like middleware and tools in the cloud for deploying your API like API gateways. To get started, you'll want to open up Versus code to an empty directory. You'll need to have Node. Js installed, and I'm using version 12 for this video. To start a new Node project, let's run npm init y from the command line. This will create a package JSON and give us a context for installing packages that we can use in Node like Express. Let's go ahead and install Express using npm install. You'll notice that adds express to our dependencies in the package JSON file. From there, we'll need a file to write our code in, so let's create an index dotjs file. At the top of that file, we'll declare a variable for app, which represents the actual API that we're building. And its value is an import of the express package, which itself is a function, so we'll add parenthesis after it to initialize it. Now at this point, our API has in to find any endpoint, but let's go ahead and run it anyway. The way you fire up your API on the server is by calling app dot listen. That tells it to listen on a specific port, which we've defined as its own separate variable as 8080. Then as an optional second argument To listen, we can fire a callback to let us know when the API is ready, and we'll just have it console log the main URL. We can now run the API by going to the terminal and running node period to run that index dot JS file. And it should console log, it's alive on local host 8080. If we paste the URL into the browser, you can see we get a message of cannot get. That's because we don't have any API endpoints set up yet, but Express is still responding with an error message. In fact, you can open up the network tab in Chrome. If we look closely, we can see that our server responded with a 404 status code, meaning that page was not found. At this point, we know our API is working, but debugging it in the browser is usually not the best option. There are many different ways we can access our API. We could use curl from the command line, we can install a Versus Code extension, or we could use a REST client like Insomnia or Postman. I'm going to be using Insomnia throughout the rest of this video because it provides a really nice way to format your requests and also via history of all your interactions. From Insomnia, We can create a new request, then simply paste in our URL. We can easily change the HTTP verb from the drop down menu here, Click Send and then get the response in a nicely formatted developer friendly way. We can even see the timeline here with our request in yellow and the response in green. But now we need to get back to our JavaScript and add an endpoint to the API. We can do that by chaining an HTTP verb to the app instance. If you type a period after app, you'll get IntelliSense on a bunch of different methods that live on this object, and you'll notice methods for git, post, patch, etcetera, which represent different HTTP verbs. If we want to add a git endpoint to the t shirt URI, we can do that by passing /tshirt as its first argument. That'll automatically set up our server with that endpoint, then it's our job to handle a request to it, which we do by passing a callback function as the second argument. Whenever a client or end user requests that URL, it will fire this callback function to handle the request. The function itself provides access to 2 different objects, the request object and the response object. The request is the incoming data, while the response is the data we want to send back to the client. The most important thing it does is allow us to send a response back to the client. That response can have a status code like 200 for an okay response, then we can send a data payload along with it. If we pass a JavaScript object as the argument, then it will send that data back as JSON by default. Let's go ahead and save the file, then restart server from the terminal. From Insomnia, we can then make a get request to local host 8080/t shirt. When we do that, We get a JSON object back as the response body with a status code of 200. That's pretty cool. But now let's go back to our code and add a second endpoint, This time, a post endpoint followed by a slash and a dynamic URL parameter that represents the ID of that t shirt. There might be millions of different t shirts on this API and a dynamic URL allows us to handle all of them from a single function. When dealing with a post request, It means that the user is trying to create new data on the server or create a new t shirt in this case. First, we need the ID, which we can get from the URL, and its value is made available to us on the request parameters object. 2nd, we also need a logo for the t shirt, But the logo is contained in the request body, which if you remember from earlier, is a custom data payload contained in the incoming request. In other words, the request Object and Express allows us to access information from the request message, like the URL parameters, the body, the headers, etcetera. And now that we have that information, we could use it to save a new record to the database or something along those lines. That's beyond the scope of this video. What we'll do for Right now is check to make sure that we have a logo in the request body, and if we don't, then we'll send an error response with a 4 18 status code and an error message that we need a logo. But assuming we do have a valid logo, we can just send a response with a t shirt that contains that logo and ID. Now let's go back to Insomnia, and we'll make a post request to that t shirt endpoint followed by a unique ID that can be whatever you want. Then in the body section, we'll go ahead and add a request body with a format of JSON, and it's just a JSON object that contains a logo with a string value. If we send that request, you'll notice we get a 500 error response, which means our API code is broken. So what's going on here? It's telling us we have a runtime error because we can't destructure the property Mogo from the request body. The reason for that is that Express does not parse JSON in the body by default. Not everybody uses Express to build a JSON API, so that's not the default behavior. What we need to do here is set up middleware that tells Express to parse JSON before the actual data It's the function that we're using here to handle the request. When you hear the term middleware, think of shared code that runs before every endpoint callback Mac, that you've defined. Very common middleware is built into Express itself. We can refactor our code here a little bit to make a variable for Express, And then we can call app dot use to apply middleware. In this case, the middleware we want to apply is the express dotjsonmiddleware. Now every request that comes in will first go through this express JSON middleware, which will convert the body to JSON, therefore, making it available both in our post callback. Let's go ahead and save, restart our server, and then go back to Insomnia. And if we send the same exact request, you'll notice this time, We get back a successful response. In addition, if we make the logo an empty string and try to send the same request, We get a 4 18 response along with a message that we need a logo. Congratulations. You just built a restful API from scratch with no JS and express. But before we wrap up the video, there's one more thing you should definitely know about when it comes to restful APIs. And that is the open API my spec, which provides a standard way to describe an API in YAML. It originally came about in something called the swagger framework, and what it allows you to do is describe your API in a way that can be understood by both humans and machines. And if you're building a serious API, you get all kinds of awesome benefits in the process. Your API will be fully documented, making it much easier for the end user to work with. And because it follows a standard format, you can actually just automatically generate all of your client side or server side code. What I'm using right now is a free tool called Swagger Hub, and I can come up here and hit the export button to automatically generate a bunch of boilerplate code. Now I'm usually not a huge fan of code generators, but there's a more powerful reason to use OpenAPI. When you describe your API With the open API spec, you can then upload the configuration to tools like API Gateway on AWS or Google Cloud, where it can be secured, monitored, and connected to back end infrastructure. Let me know if you wanna see a full tutorial on that topic, but I'm gonna go ahead and wrap things up there. And if you want access to even More advanced content, consider becoming a pro member at FireShip IO. Thanks for watching, and I will see you in the next one.
The speakers discuss using restful APIs and Express JS in web applications and creating new APIs from scratch. They stress the importance of creating a logo for requests and discuss setting up post variables and logs. The use of AWS and Azure for code development is emphasized, along with a free tool for developers to use to generate boilerplate code.

        [INST]
        You are youtuber called Fireship you make engaging high-intensity and entertaining coding tutorials and tech news. 
        you covers a wide range of topics relevant to programmers, aiming to help them learn and improve their skills quickly.
        
        Given the title of the video : RESTful APIs in 100 Seconds // Build an API from Scratch with Node.js Express 
        and a small summary : The speakers discuss using restful APIs and Express JS in web applications and creating new APIs from scratch. They stress the importance of creating a logo for requests and discuss setting up post variables and logs. The use of AWS and Azure for code development is emphasized, along with a free tool for developers to use to generate boilerplate code.
        [/INST]
        
        Generate the video : An application programming interface or API is a way for 2 computers to talk to each other. Using an API is just like using a website in your browser, but instead of clicking buttons and filling out forms, you write code to explicitly request data from a server. For example, we could visit the NASA a website to look at asteroids, or we could use their rest API to request the raw JSON data that is shown on the screen. Now most APIs in The world are restful, which means they follow a set of rules or constraints known as representational state transfer, which has been the de facto standard for API development since the early 2000. A restful API organizes data entities or resources into a bunch of unique URLs. Well, technically not URLs, but u r i's or uniform resource identifiers that differentiate different types of data resources on a server. A client can get data about a resource by making a request to that endpoint over HTTP. The request Message has a very specific format. Most importantly, the start line contains the URI that you wish to access, which is preceded by an HTTP verb or request method, which signal your intent with the resource. A git request means you just want to read the data, while post means you want to create a new resource. Patch is for Updates, delete is for removing data, along with a few other methods beyond those. Below the start line, we have headers, which contain metadata about the request. The accept header can tell the server you want the data in a specific format, or the authorization header can be used to tell the server that you're actually allowed to make that request. Then following the headers, we have the body, which contains a custom payload of data. The server will receive the request message, then execute some code, usually to read from a database, that can then be formatted into a response message. The top of the message contains a status code to tell the client what happened to their request. Codes at the 200 level mean that things went well. At the 400 level, it means something was wrong with your request. And at the 500 level, it means that the server failed. After for the status code, we then have the response headers, which contain information about the server. That's followed by the response body, which contains the data payload and is usually formatted in JSON when talking about APIs. Now an important part of this architecture is that it's stateless, which means that the 2 parties don't need to store any information about each other, and every request response cycle is independent from all other communication. And this leads to well behaved web applications that are predictable and reliable. This has been restful APIs in 100 seconds. If you enjoyed it, leave a comment below. Then next week, I'll pick out the best one to win this free t shirt. And now it's time to go beyond 100 seconds to build a restful API from scratch. The most popular framework for building restful APIs in Node is Express JS. It's been around forever and it's very minimal and easy to learn if you know a little bit of JavaScript. Over the next few minutes, we'll use Express to build our own restful API from scratch. You'll learn how to create different endpoints for your API. We'll also look at slightly more advanced concepts like middleware and tools in the cloud for deploying your API like API gateways. To get started, you'll want to open up Versus code to an empty directory. You'll need to have Node. Js installed, and I'm using version 12 for this video. To start a new Node project, let's run npm init y from the command line. This will create a package JSON and give us a context for installing packages that we can use in Node like Express. Let's go ahead and install Express using npm install. You'll notice that adds express to our dependencies in the package JSON file. From there, we'll need a file to write our code in, so let's create an index dotjs file. At the top of that file, we'll declare a variable for app, which represents the actual API that we're building. And its value is an import of the express package, which itself is a function, so we'll add parenthesis after it to initialize it. Now at this point, our API has in to find any endpoint, but let's go ahead and run it anyway. The way you fire up your API on the server is by calling app dot listen. That tells it to listen on a specific port, which we've defined as its own separate variable as 8080. Then as an optional second argument To listen, we can fire a callback to let us know when the API is ready, and we'll just have it console log the main URL. We can now run the API by going to the terminal and running node period to run that index dot JS file. And it should console log, it's alive on local host 8080. If we paste the URL into the browser, you can see we get a message of cannot get. That's because we don't have any API endpoints set up yet, but Express is still responding with an error message. In fact, you can open up the network tab in Chrome. If we look closely, we can see that our server responded with a 404 status code, meaning that page was not found. At this point, we know our API is working, but debugging it in the browser is usually not the best option. There are many different ways we can access our API. We could use curl from the command line, we can install a Versus Code extension, or we could use a REST client like Insomnia or Postman. I'm going to be using Insomnia throughout the rest of this video because it provides a really nice way to format your requests and also via history of all your interactions. From Insomnia, We can create a new request, then simply paste in our URL. We can easily change the HTTP verb from the drop down menu here, Click Send and then get the response in a nicely formatted developer friendly way. We can even see the timeline here with our request in yellow and the response in green. But now we need to get back to our JavaScript and add an endpoint to the API. We can do that by chaining an HTTP verb to the app instance. If you type a period after app, you'll get IntelliSense on a bunch of different methods that live on this object, and you'll notice methods for git, post, patch, etcetera, which represent different HTTP verbs. If we want to add a git endpoint to the t shirt URI, we can do that by passing /tshirt as its first argument. That'll automatically set up our server with that endpoint, then it's our job to handle a request to it, which we do by passing a callback function as the second argument. Whenever a client or end user requests that URL, it will fire this callback function to handle the request. The function itself provides access to 2 different objects, the request object and the response object. The request is the incoming data, while the response is the data we want to send back to the client. The most important thing it does is allow us to send a response back to the client. That response can have a status code like 200 for an okay response, then we can send a data payload along with it. If we pass a JavaScript object as the argument, then it will send that data back as JSON by default. Let's go ahead and save the file, then restart server from the terminal. From Insomnia, we can then make a get request to local host 8080/t shirt. When we do that, We get a JSON object back as the response body with a status code of 200. That's pretty cool. But now let's go back to our code and add a second endpoint, This time, a post endpoint followed by a slash and a dynamic URL parameter that represents the ID of that t shirt. There might be millions of different t shirts on this API and a dynamic URL allows us to handle all of them from a single function. When dealing with a post request, It means that the user is trying to create new data on the server or create a new t shirt in this case. First, we need the ID, which we can get from the URL, and its value is made available to us on the request parameters object. 2nd, we also need a logo for the t shirt, But the logo is contained in the request body, which if you remember from earlier, is a custom data payload contained in the incoming request. In other words, the request Object and Express allows us to access information from the request message, like the URL parameters, the body, the headers, etcetera. And now that we have that information, we could use it to save a new record to the database or something along those lines. That's beyond the scope of this video. What we'll do for Right now is check to make sure that we have a logo in the request body, and if we don't, then we'll send an error response with a 4 18 status code and an error message that we need a logo. But assuming we do have a valid logo, we can just send a response with a t shirt that contains that logo and ID. Now let's go back to Insomnia, and we'll make a post request to that t shirt endpoint followed by a unique ID that can be whatever you want. Then in the body section, we'll go ahead and add a request body with a format of JSON, and it's just a JSON object that contains a logo with a string value. If we send that request, you'll notice we get a 500 error response, which means our API code is broken. So what's going on here? It's telling us we have a runtime error because we can't destructure the property Mogo from the request body. The reason for that is that Express does not parse JSON in the body by default. Not everybody uses Express to build a JSON API, so that's not the default behavior. What we need to do here is set up middleware that tells Express to parse JSON before the actual data It's the function that we're using here to handle the request. When you hear the term middleware, think of shared code that runs before every endpoint callback Mac, that you've defined. Very common middleware is built into Express itself. We can refactor our code here a little bit to make a variable for Express, And then we can call app dot use to apply middleware. In this case, the middleware we want to apply is the express dotjsonmiddleware. Now every request that comes in will first go through this express JSON middleware, which will convert the body to JSON, therefore, making it available both in our post callback. Let's go ahead and save, restart our server, and then go back to Insomnia. And if we send the same exact request, you'll notice this time, We get back a successful response. In addition, if we make the logo an empty string and try to send the same request, We get a 4 18 response along with a message that we need a logo. Congratulations. You just built a restful API from scratch with no JS and express. But before we wrap up the video, there's one more thing you should definitely know about when it comes to restful APIs. And that is the open API my spec, which provides a standard way to describe an API in YAML. It originally came about in something called the swagger framework, and what it allows you to do is describe your API in a way that can be understood by both humans and machines. And if you're building a serious API, you get all kinds of awesome benefits in the process. Your API will be fully documented, making it much easier for the end user to work with. And because it follows a standard format, you can actually just automatically generate all of your client side or server side code. What I'm using right now is a free tool called Swagger Hub, and I can come up here and hit the export button to automatically generate a bunch of boilerplate code. Now I'm usually not a huge fan of code generators, but there's a more powerful reason to use OpenAPI. When you describe your API With the open API spec, you can then upload the configuration to tools like API Gateway on AWS or Google Cloud, where it can be secured, monitored, and connected to back end infrastructure. Let me know if you wanna see a full tutorial on that topic, but I'm gonna go ahead and wrap things up there. And if you want access to even More advanced content, consider becoming a pro member at FireShip IO. Thanks for watching, and I will see you in the next one.
        