Understanding the basics of RESTful APIs

Understanding the basics of RESTful APIs

In this tutorial, we will explore the basics of APIs, what we can use them for, how to design them and various ways we can protect them. We will also look at situations where we may not need to design an API of our own and where we can use a service like Pusher to provide data.

Application programming interfaces (APIs) provide the platform and medium for applications to talk to and understand each other. APIs specify the way information passed across platforms is structured so that applications can exchange data and information.

REST is an API architecture style. It stands for representational state transfer. REST specifies how data is presented to a client in a format that is convenient for the client. Data exchanges happen either in JSON or XML format. However, many APIs today return JSON data, so we will focus on that in this guide.


Prerequisites
  • Basic knowledge of application development in any server-side language like Node.js or PHP
Optional requirementsUnderstanding how data is exchanged over the web

For simplicity, we will keep this section to the basics. Enough to give a clear idea of how data is exchanged over the internet through TCP/IP (transmission control protocol/internet protocol). TCP/IP is a suite of communication protocols that describes how the vast number of computers connected to the internet interact.

TCP/IP provides end-to-end communications that specifies how data is exchanged over the internet, how data is broken into packets, how the packets are encoded, addressed, routed and received at the destination. Think of it like this giant mail company that has the ability to deliver your packages anywhere in the world incredibly fast. TCP/IP will specify the rules for preparing each of the packages so they get to the right person without a mix up. It is also cooler in that there are public packages available to everyone and you can request a copy sent to you.

TCP/IP uses the standard client-server communication model, where a client (computer device) requests a resource from a server (possibly a much larger computer device in a remote location). Connections using TCP/IP are stateless — every request from a client to a server is treated as new, the server never remembers a client. This frees up resources on the server to make it faster and respond to multiple requests quicker.

You can read more about TCP/IP on this article by Search Target.
Understanding how APIs enable applications talk to each other

You must be wondering “Okay, that was cool, but how does it relate to anything?”. APIs are like the TCP/IP for applications. It specifies how applications interact and exchange data between each other. Like TCP/IP, RESTful APIs are stateless. All requests using the API have to contain as much information as possible for the server to identify the client.

The API specifies a set of rules for one application to interact with another. Many APIs have proper documentation that also describes the nature and structure of the response they send when you make a request. They also specify the necessary information a requesting application needs to provide to make a successful request to the API.

In effect, RESTful APIs function just about the same way standard TCP/IP requests function, except there are no clients and servers here, but just two applications talking to each other.


Brief about different API patterns

There are a number of patterns for designing APIs. These patterns have history, different requirements and create different experiences for users. These designs are somehow interconnected with each other, so we will see many places where they are very similar. Understanding them will help you in making a decision of which to use to address your specific issues.


Tunneling style

Tunneling works like a system of remote procedure calls (RPCs) organized in an XML message format. RPC in itself is a really old technology that is best suited for communicating commands and procedures. It is used currently in platforms like Ethereum and has native support in Golang. Tunneling is used by SOAP in some instances, but we will not look into that.


SOAP - Simple object access protocol

SOAP can be argued to be a communication protocol rather than an API architecture/pattern because it defines its set of communication rules and security protocols and all of that. SOAP APIs carry more overhead than their counterparts, but they come with their own benefits. For one, they provide more security when designing large scale enterprise applications.

Many of the reasons to pick SOAP include features around security, transactions, and ACID (atomicity, consistency, isolation, durability) compliance, all of which rarely apply to web services scenarios, hence its stronger appeal to enterprise scale applications.


REST

REST is truly a “web services” API putting it on the opposite side of SOAP (probably why you will see a dozen comparisons on them without looking too much). REST APIs are based on URIs (uniform resource identifier) and the HTTP protocol. REST APIs can exchange data in either JSON or XML format, although many REST APIs send data as JSON.

When building a system with minimal security considerations but strong speed requirements, REST is an excellent choice. RESTful APIs have fewer security requirements, boost browser client compatibility, discoverability, data health, and scalability—things that really apply to web services.


RESTful APIs — design considerations

We had defined and used a few simple RESTful API endpoints in the previous article on Understanding HTTP response codes in frontend applications - Part 2. Please read the article before continuing with the rest of this article.

Designing APIs are an entirely different thing. There are best practices to consider to ensure your APIs are easy for anyone to consume. Let’s list of five of them below:


Use plural nouns and not verbs

As an example, imagine you want a service for stock control of fruits. Here is a simple chart of basic REST APIs you can make for your fruit application

Resource GET read POST create PUT update DELETE /fruits Returns a list of fruits possibly all the fruits you have Create a new fruit Bulk update of fruits (you may never have to do this) Delete all fruits (you should probably not implement this) /fruits/1004 Returns a specific fruit Method not allowed (405) Updates a specific fruit Deletes a specific fruit It’s not good practice to have API endpoints like /getFruits or /delete-fruits or /createfruits. Instead, take advantage of HTTP verbs for the definitions. This means I can easily build upon your APIs and have fewer resources to manage. This approach is less ambiguous and cleaner.

Try not to mix singular and plural nouns. Use plural nouns since you typically fetch resources by their IDs. There are situations where singular nouns work, but they should be use sparingly.

GET method and its query parameters should not alter the state

Avoid designing endpoints like this

    GET /fruits/1004?avaliable=false
    GET /fruits/1004/has-finished 

with the intention of those endpoints setting the availability of the fruits. I know when you read it, it sounds intuitive, but it is very bad for your application. If a search engine’s bot or any web crawler ever gets hold of that URL …

If you must alter state, use POST, PUT or DELETE like our table above.

You can read Well Intentioned Destruction — a real life example of when this happened.

Use sub-resources for relations

Say you are designing a social network where users have blogs, you should establish relationships like this:

    GET /users/1004/blogs

This should fetch all the user’s blogs. If you want to fetch a specific blog, you can do the following:

    GET /users/1004/blogs/1010

Handle errors with HTTP status codes

We did a full guide on HTTP status codes explaining their use cases. You need to understand that it is hard to work with an API that ignores error handling. Returning the wrong status codes, or returning a stack trace without a helpful message highlighting the error does not help the user of the API. It does not matter if you have documentation or not.


Provide pagination, sorting and filtering

This is a no brainer. Your application will likely have a huge repository of information. I do not want to call your endpoints to get all fruits and have 100,000 fruits sent to me at the same time. You do not want to do that even. The overload on your server will be crazy and you will burn up your resources rapidly.

Also, I want a way to select only fruits that say fall into the citrus family or fruits that are found in a specific country. I also want to sort them either alphabetically or by some other sorting method you have. These are the little things that will improve how I use your API.


Basics about API security

I know I had mentioned earlier that RESTful APIs have few security considerations, but that does not mean we should ignore security completely. We will approach API security from two perspectives: authentication and authorization.


Authentication

This has to do with verifying the identity of the person trying to access your API. This can be done through multiple ways. At the simplest form, this is providing a username/email and password combination. For APIs, it will most likely involve using a security token which will identify a user. More complex scenarios will have key/secret pairs often used to integrate one application into another.


Authorization

This answers the question of “What can you do”, indicating it comes after authentication. Authorization comes in handy when you are designing endpoints for accessing data that is either very specific to a particular person or sensitive information only a predefined set of people can access.

The Pusher blog has a lot of articles on authentication/authorization for APIs, so please check those out.
When to use a service like Pusher instead

Pusher provides hosted APIs for building quick, secure realtime applications. This includes but is not limited to applications for communication and collaboration.

Whenever you have to build applications that require realtime results, rather than build API endpoints users have to poll every minute or few minutes to get the latest data/information, use Pusher. Pusher provides channels that are equipped with a subscribe/broadcast feature that will allow your users get subscribed to receive data on a particular channel while your server broadcasts data on that channel.

If I want to build analytics into my public forum to allow users see the interactions their posts are getting from a dashboard, I will use Pusher to make realtime updates to the data they see. Imagine how amazing it will be seeing the comments on your blog as they happen in realtime. Imagine the massive improvement it will make to your application.

Building an API on your server for that will require polling the server periodically to get that data. This can work assuming we are not worried about server resources, but it still does not happen in realtime. It happens on scheduled time, which won’t serve completely.


Conclusion

In this tutorial, we looked at RESTful APIs and a few things to consider when designing them. We looked briefly through the different API patterns so you can see if there is something different that might solve the problem you seek.

While this is not a definitive guide to building RESTful APIs, you now have knowledge of them and can get started building APIs that so many people can use.

Learn More

How to build a Laravel REST API with Test-Driven Development

Building A REST API With MongoDB, Mongoose, And Node.js

Creating RESTful APIs with NodeJS and MongoDB Tutorial

How to build RESTful APIs with ASP.NET Core

Build a web scraper with Node

How to Perform Web-Scraping using Node.js

MEAN Stack Tutorial MongoDB, ExpressJS, AngularJS and NodeJS

Full Stack Developers: Everything You Need to Know

Originally published by Abati Adewale at https://pusher.com

Creating a RESTful Web API with Node.js and Express.js from scratch

Creating a RESTful Web API with Node.js and Express.js from scratch

In this article, I’ll show you step by step how to create a RESTful Web API with Node.js and Express.js by building a simple and useful Todo API. This article assumes you have basic javascript knowledge and terminal using capabilities.

In this article, I’ll show you step by step how to create a RESTful Web API with Node.js and Express.js by building a simple and useful Todo API. This article assumes you have basic javascript knowledge and terminal using capabilities.

You can also build a Web API in Node.js by using another framework except Express.js but Express.js is one of the most popular web framework for Node.js.

You can found the final source code of this Web API in this github repository.

Let’s start to create our mentioned Web API.

Before start

If you have never used Node.js or npm package manager you should install them.

To check whether the Node.js is already installed on your computer, open your terminal and run node -v command. If you see your Node.js version it's installed. Otherwise go to below link.

Click here to download and install Node.js (You can choose LTS version)

And if you don’t have any IDE or text editor for writing javascript I advice you Visual Studio Code.

Click here to download VS Code (Optional)

About express-generator

In fact we could use <a href="https://expressjs.com/en/starter/generator.html" target="_blank">express-generator</a> tool which designed to creating an Express Web API quickly but I want to create this API from scratch because of that tool puts some extra files and folder structures that we don't need them now. But you can use this useful tool next time on creating new Web API. I won't use it now due to keep article simple.

Creating Project

Go to your workspace root folder and create a new folder there named "todo-api".

Then create "package.json" and "server.js" files into "todo-api" folder like below.

package.json

{
    "name": "todo-api",
    "version": "1.0.0",
    "scripts": {
        "start": "node server.js"
    },
    "dependencies": {
        "express": "^4.16.4"
    }
}

server.js

const http = require('http');
const express = require('express');
const app = express();
app.use(express.json());
app.use('/', function(req, res) {
    res.send('todo api works');
});
const server = http.createServer(app);
const port = 3000;
server.listen(port);
console.debug('Server listening on port ' + port);

After creating above files open your terminal in the "todo-api" folder and run npm installcommand.

This command will be install your project dependencies which pointed at the "package.json" file.

After finished package download process, downloaded dependency files will be installed into"node_modules" folder at the root of the "todo-api" folder.

After finished package installing then run npm start to start our Web API.

Now our Web API listening. To see result open your web browser then write localhost:3000 to address bar and press enter.

As result you’ll see our request handler response in your browser: “todo api works”.

This is a dead simple Express.js Web API. And it needs the some development. For example we need to an api endpoint to get todo items. So let’s add a new API endpoint for this.

Create a new folder named "routes" in the root of the "todo-api" folder.

Then create a "items.js" file inside of "routes" folder and put following codes inside it.

Your final folder structure should be like below;

/todo-api
/node_modules
/routes
    items.js
package.json
server.js

items.js

const express = require('express');
const router = express.Router();
const data = [
    {id: 1, title: 'Finalize project', order: 1, completed: false, createdOn: new Date()},
    {id: 2, title: 'Book ticket to London', order: 2, completed: false, createdOn: new Date()},
    {id: 3, title: 'Finish last article', order: 3, completed: false, createdOn: new Date()},
    {id: 4, title: 'Get a new t-shirt', order: 4, completed: false, createdOn: new Date()},
    {id: 5, title: 'Create dinner reservation', order: 5, completed: false, createdOn: new Date()},
];
router.get('/', function (req, res) {
    res.status(200).json(data);
});
router.get('/:id', function (req, res) {
    let found = data.find(function (item) {
        return item.id === parseInt(req.params.id);
    });
    if (found) {
        res.status(200).json(found);
    } else {
        res.sendStatus(404);
    }
});
module.exports = router;

Initial code of "items.js" file contains two endpoints. First one gets all todo items and second one gets one item which matches given id parameter.

Before testing items routes we should register it in the "server.js" file.

Modify "server.js" file like below to register new item routes.

server.js

const http = require('http');
const express = require('express');
const itemsRouter = require('./routes/items');
const app = express();
app.use(express.json());
app.use('/items', itemsRouter);
app.use('/', function(req, res) {
    res.send('todo api works');
});
const server = http.createServer(app);
const port = 3000;
server.listen(port);
console.debug('Server listening on port ' + port);

Now run npm start to start our Web API.

Then open your web browser and write localhost:3000/items to address bar and press enter.

You’ll see todo items json array in the response body.

And write localhost:3000/items/3 to address bar and press enter.

You’ll see the todo item which has id 3 in the response body.

But not finished up yet.

CRUD Operations and HTTP methods

I think we’ll need CRUD operations to Create, Read, Update and Delete todo items.

We have already two endpoints for getting items. So we need Create, Update and Delete endpoints.

Let’s add also these endpoints into the items.js file.

Our final "items.js" file and endpoints should be like below.

const express = require('express');
const router = express.Router();

const data = [
  {id: 1, title: 'Finalize project',          order: 1, completed: false, createdOn: new Date()},
  {id: 2, title: 'Book ticket to London',     order: 2, completed: false, createdOn: new Date()},
  {id: 3, title: 'Finish last article',       order: 3, completed: false, createdOn: new Date()},
  {id: 4, title: 'Get a new t-shirt',         order: 4, completed: false, createdOn: new Date()},
  {id: 5, title: 'Create dinner reservation', order: 5, completed: false, createdOn: new Date()},
];

router.get('/', function (req, res) {
  res.status(200).json(data);
});

router.get('/:id', function (req, res) {
  let found = data.find(function (item) {
    return item.id === parseInt(req.params.id);
  });

  if (found) {
    res.status(200).json(found);
  } else {
    res.sendStatus(404);
  }
});

router.post('/', function (req, res) {
  let itemIds = data.map(item => item.id);
  let orderNums = data.map(item => item.order);

  let newId = itemIds.length > 0 ? Math.max.apply(Math, itemIds) + 1 : 1;
  let newOrderNum = orderNums.length > 0 ? Math.max.apply(Math, orderNums) + 1 : 1;

  let newItem = {
    id: newId,
    title: req.body.title,
    order: newOrderNum,
    completed: false,
    createdOn: new Date()
  };

  data.push(newItem);

  res.status(201).json(newItem);
});

router.put('/:id', function (req, res) {
  let found = data.find(function (item) {
    return item.id === parseInt(req.params.id);
  });

  if (found) {
    let updated = {
      id: found.id,
      title: req.body.title,
      order: req.body.order,
      completed: req.body.completed
    };

    let targetIndex = data.indexOf(found);

    data.splice(targetIndex, 1, updated);

    res.sendStatus(204);
  } else {
    res.sendStatus(404);
  }
});

router.delete('/:id', function (req, res) {
  let found = data.find(function (item) {
    return item.id === parseInt(req.params.id);
  });

  if (found) {
    let targetIndex = data.indexOf(found);

    data.splice(targetIndex, 1);
  }

  res.sendStatus(204);
});

module.exports = router;

Short Explanation

I wanna explain shortly some points of our last codes.

First of all you must have noticed that our api works on a static data and keeps it on memory. All of our GET, POST, PUT and DELETE http methods just manipulate a json array. The purpose of this is to keep article simple and draw attention to the Web API structure.

Due to this situation our POST method has some extra logic such as calculating next item ids and order numbers.

So you can modify logic and data structures in these http methods to use a database or whatever you want.

Testing API with Postman

We have tested the GET methods of our Web API in our web browser and seen responses. But we can’t test directly POST, PUT and DELETE http methods in web browser.

If you want to test also other http methods you should use Postman or another http utility.

Now I’ll show you how to test the Web API with Postman

Before we start click here and install Postman.

When you first launch Postman after installing you’ll see start window. Close this start window by clicking close button on top right corner. Then you must see following screen.

An empty Postman request

Sending GET Request

Before sending a request to API we should start it by running npm startcommand as we do before.

After start the Web API and seeing “Server listening on…” message write localhost:3000/itemsto address bar as seen below and click Send button. You'll see todo items array as API response like below.

Sending a GET request with Postman

You can try similarly by giving an item id in request url like this localhost:3000/items/3

Sending POST Request

To sending a POST request and create a new todo item write localhost:3000/items to address bar and change HTTP verb to POST by clicking arrow at front of the address bar as seen below.

Sending a POST request with Postman

Before sending the POST request you should add request data to body of the request by clicking body tab and selecting raw and JSON as seen below.

Attaching a JSON body to POST request in Postman

Now click Send button to send POST request to the Web API. Then you must get “201 Created” http response code and seeing created item in the response body.

To see the last status of todo items send a get request to localhost:3000/itemsaddress. You must see newly created item at the end of the list.

Sending PUT Request

Sending PUT request is very similar to sending POST request.

The most obvious difference is request url should be pointed specific item like this localhost:3000/items/3

And you should choose PUT as http verb instead of POST and send all of the required data in the request body unlike POST.

For example you could send a JSON body in the PUT request as below.

An example JSON body for PUT request

{
    "title": "New title of todo item",
    "order": 3,
    "completed": false
}

When you click Send button you must get “204 No Content” http response code. You can check item you updated by sending a get request.

Sending DELETE Request

To send a DELETE request, change the request url to address a specific item id like this localhost:3000/items/3

And select DELETE as http verb and click Send button.

You must get “204 No Content” http response code as result of the DELETE operation.

Send a get request and see the last status of list.

About the DELETE Http Request

I want to say a few words about DELETE http request. You must have noticed something in our delete code. DELETE request returns “204 No Content” every situation.

Http DELETE requests are idempotent. So what that mean? If you delete a resource on server by sending DELETE request, it’s removed from the collection. And every next DELETE request on the same resource won’t change outcome. So you won’t get “404 Not Found” in the second request. Each request returns same response whether succeed or not. That’s mean idempotent operation.

Conclusion

Finally we’ve tested all http methods of our Web API.

As you can see, it works just fine.

Thanks for reading ❤

If you liked this post, share it with all of your programming buddies!

Develop this one fundamental skill if you want to become a successful developer

Throughout my career, a multitude of people have asked me&nbsp;<em>what does it take to become a successful developer?</em>

Throughout my career, a multitude of people have asked me what does it take to become a successful developer?

It’s a common question newbies and those looking to switch careers often ask — mostly because they see the potential paycheck. There is also a Hollywood level of coolness attached to working with computers nowadays. Being a programmer or developer is akin to being a doctor or lawyer. There is job security.

But a lot of people who try to enter the profession don’t make it. So what is it that separates those who make it and those who don’t? 

Read full article here

How to create a REST API with Node.js

How to create a REST API with Node.js

In this article, you'll learn the process of building REST API with Node.js from scratch.

What is REST API?

REST or RESTful stands for REpresentational State Transfer. It is an architectural style as well as an approach for communications purpose that is often used in various web services development. In simpler terms, it is an application program interface (API) which makes use of the HTTP requests to GET, PUT, POST and DELETE the data over WWW.

REST architectural style helps in leveraging the lesser use of bandwidth which makes an application more suitable for the internet. It is often regarded as the “language of the internet”. It is completely based on the resources where each and every component is regarded as a component and a single resource is accessible through a common interface using the standard HTTP method.

To understand better, let’s dive a little deeper and see how exactly does a REST API work. Basically, the REST API breaks down a transaction in order to create small modules. Now, each of these modules is used to address a specific part of the transaction. This approach provides more flexibility but requires a lot of effort to be built from the very scratch.

The main functions used in any REST based architecture are:

  • GET − Provides read-only access to a resource.
  • PUT − Creates a new resource.
  • DELETE − Removes a resource.
  • POST − Updates an existing resource or creates a new resource.

But all who claims cannot be referred to as RESTful API. In order to be regarded as a RESTful API, your application must satisfy certain constraints or principles. In the next section of this article on Building a REST API using Node.js, I will be talking about these principles in detail.

Principles of REST

Well, there are six ground principles laid down by Dr. Fielding who was the one to define the REST API design in 2000. Below are the six guiding principles of REST:

  1. Stateless
  2. Requests sent from a client to the server contains all the necessary information that is required to completely understand it. It can be a part of the URI, query-string parameters, body, or even headers. The URI is used for uniquely identifying the resource and the body holds the state of the requesting resource. Once the processing is done by the server, an appropriate response is sent back to the client through headers, status or response body.
  3. Client-Server
  4. It has a uniform interface that separates the clients from the servers. Separating the concerns helps in improving the user interface’s portability across multiple platforms as well as enhance the scalability of the server components.
  5. Uniform Interface
  • To obtain the uniformity throughout the application, REST has defined four interface constraints which are:Resource identification
  • Resource Manipulation using representations
  • Self-descriptive messages
  • Hypermedia as the engine of application state
  1. Cacheable
  2. In order to provide a better performance, the applications are often made cacheable. It is done by labeling the response from the server as cacheable or non-cacheable either implicitly or explicitly. If the response is defined as cacheable, then the client cache can reuse the response data for equivalent responses in the future. It also helps in preventing the reuse of the stale data.
  3. Layered system
  4. The layered system architecture allows an application to be more stable by limiting component behavior. This architecture enables load balancing and provides shared caches for promoting scalability. The layered architecture also helps in enhancing the application’s security as components in each layer cannot interact beyond the next immediate layer they are in.
  5. Code on demand
  6. Code on Demand is an optional constraint and is used the least. It permits a clients code or applets to be downloaded and extended via the interface to be used within the application. In essence, it simplifies the clients by creating a smart application which doesn’t rely on its own code structure.

Now that you know what is a REST API and what all you need to mind in order to deliver an efficient application, let’s dive deeper and see the process of building REST API using Node.js.

Practical Demonstration: Building REST API using Node.js

Here, we will be creating a simple CRUD REST application for Library Management using Node.js and Express.js. To build this application, you will need to install the following:

  1. Node.js
  2. Express.js
  3. Joi
  4. nodemon (Node Monitor)

In this example, I will be using the WebStorm IDE to write and execute the codes. You can use any IDE or code editor according to your choice. So, let’s get started.

First, you need to create your project directory. Next, open the command prompt and navigate to your project directory. Once there, you need to call npm using the below command:

npm init

When you hit enter, Node.js will ask you to enter some details to build the .json file such as:

Here you can define your entry point along with several other information. For this demo, I will be using script.js as an entry point. Next, we will be installing Express.js using the below command:

npm i express

Finally, I will be installing a node monitoring package called nodemon. It keeps a watch on all the files with any type of extension present in this folder. Also, with nodemon on the watch, you don’t have to restart the Node.js server each time any changes are made. nodemon will implicitly detect the changes and restart the server for you.

npm i -g nodemon

package.json

{
"name": "samplerestapi",
"version": "1.0.0",
"description": "Edureka REST API with Node.js",
"main": "script.js",
"scripts": {
"test": "echo "Error: no test specified" && exit 1"
},
"author": "Edureka",
"license": "ISC",
"dependencies": {
"express": "^4.16.4",
"joi": "^13.1.0"
}
}

script.js

const express = require('express');
const Joi = require('joi'); //used for validation
const app = express();
app.use(express.json());

const books = [
{title: 'Harry Potter', id: 1},
{title: 'Twilight', id: 2},
{title: 'Lorien Legacies', id: 3}
]

//READ Request Handlers
app.get('/', (req, res) => {
res.send('Welcome to Edurekas REST API with Node.js Tutorial!!');
});

app.get('/api/books', (req,res)=> {
res.send(books);
});

app.get('/api/books/:id', (req, res) => {
const book = books.find(c => c.id === parseInt(req.params.id));

if (!book) res.status(404).send('<h2 style="font-family: Malgun Gothic; color: darkred;">Ooops... Cant find what you are looking for!</h2>');
res.send(book);
});

//CREATE Request Handler
app.post('/api/books', (req, res)=> {

const { error } = validateBook(req.body);
if (error){
res.status(400).send(error.details[0].message)
return;
}
const book = {
id: books.length + 1,
title: req.body.title
};
books.push(book);
res.send(book);
});

//UPDATE Request Handler
app.put('/api/books/:id', (req, res) => {
const book = books.find(c=> c.id === parseInt(req.params.id));
if (!book) res.status(404).send('<h2 style="font-family: Malgun Gothic; color: darkred;">Not Found!! </h2>');

const { error } = validateBook(req.body);
if (error){
res.status(400).send(error.details[0].message);
return;
}

book.title = req.body.title;
res.send(book);
});

//DELETE Request Handler
app.delete('/api/books/:id', (req, res) => {

const book = books.find( c=> c.id === parseInt(req.params.id));
if(!book) res.status(404).send('<h2 style="font-family: Malgun Gothic; color: darkred;"> Not Found!! </h2>');

const index = books.indexOf(book);
books.splice(index,1);

res.send(book);
});

function validateBook(book) {
const schema = {
title: Joi.string().min(3).required()
};
return Joi.validate(book, schema);

}

//PORT ENVIRONMENT VARIABLE
const port = process.env.PORT || 8080;
app.listen(port, () => console.log(`Listening on port ${port}..`));

Now, the next step is to check whether the handlers are working properly or not. For that, we will use a Chrome extension called Postman. To install Postman you can visit hereand click on ‘Add to Chrome’.

Once you have successfully installed Postman, open it and start testing your application. So, let’s start off by testing our GET method. Now, in order to do that you need to select GET from the drop-down list, type in the defined URI and hit send. If your code is working fine, then you will see the list of all the books which we have added manually in our code. In the below picture, you can see how my result looks like.

Now, let’s try adding a new book to our inventory list. For that, select ‘POST’ from the drop-down list and type in the defined URI for the POST method. Now, click on ‘Body’, select ‘raw’ and move on to select ‘JSON’ from the drop-down list as depicted in the below image. Now, in the text area, type in the title of your book as shown and hit send.

If your POST method is working fine, your response body will contain the book title along with the book id. Now, let’s try to update the book title. Currently, my book title is “Angels and Demons” which I will be updating to “Angels & Demons”. So, to update the data, you need to first select ‘PUT’ from the drop-down table and enter the PUT request’s URI along with the book id you wish to update. Next in the ‘Body’, type in the new book title and hit enter.


This will give you a response with the book id and updated book title.

Finally, let’s send a ‘DELETE’ request to delete an existing record. For that select DELETE from the drop-down list and type in the URI of the delete request handler along with the book details, you want to remove and hit enter. If your transaction is successful, you will see the complete details of the entry you have removed in the response body.

Now, let’s send a GET request for our final list of books.


As you can see from the above screenshot, the response body contains a total of three books with the book id 3 missing as we have already deleted that entry.