Why leave the IDE to test new apis? Now you don’t have to do that.

How do we get the data

If you’ve been doing Web development for a long time, you probably know that a lot of our work revolves around data: reading it, writing it, manipulating it, and displaying it in a reasonable way in the browser.

The vast majority of this data is provided by REST API endpoints, in layman’s terms: the data we want exists in another service or database, and our application queries that service to retrieve the data and uses it as it needs to.

In the past, in order to test the REST API before connecting the UI to accept data, you usually had to query the API from the command line of the terminal, or use a GUI like Insomnia or Postman (which I compared in a previous blog post).

But for now, if you use VS Code (and why not, it’s great to Code with!) “Life becomes simple. We no longer need to exit the IDE to test the API, as there is now a plug-in that does this: the REST Client.

Using the REST Client is very simple, and I’ll show you how simple and fully functional the plug-in is.

Know the VS Code REST Client plug-in

I’ve been a fan of the VS Code editor for several years, and I always appreciate it when someone creates a useful new plugin and adds it to the VS Code marketplace.

So when I decided it was a pain to launch Postman or Insomnia every time I needed to test a new API route, I found the REST Client plugin that made it unnecessary.

REST Client is the most obvious name for the tool that exists to date, and its VS Code marketing description accurately summarizes its functionality: “REST Client allows you to send HTTP requests and view responses directly in Visual Studio Code.”

It’s that simple. It then provides a lot of detail and examples of how to use it, but really it’s an HTTP tool built into VS Code. So let’s start using it.

Install a REST Client

To find it, open the Marketing extension in VS Code (the little Tetris icon on the left panel), enter “REST Client” in the search bar, and then install the first result in the list (the author should be Huachao Mao).

Once the installation is complete, we can proceed with the setup.

Set the REST Client script

Simply create a file ending in.http at the root of the project, and the REST Client recognizes this and knows that it should be able to run HTTP requests from that file.

For testing, I took a dockerized full-stack MERN login application I made a few years ago and dropped a file I named test. HTTP into the root of the project folder.

Test: Basic operations

This is the cool part: in my experience, this little REST Client plug-in can do just as much as more complex API clients like Postman.

Next, I’ll show you how to do the basic CRUD operations of each type, plus how to make authenticated API calls like JWT tokens, using the MERN user registration application I’m running locally to point to the calls.

POST the sample

The first example I’ll cover is a POST from a REST Client, because users must register to do anything else in my application (after all, this is just a login service).

Therefore, the code will be displayed in the test.http file.

Ok, let’s review what happened in the code snippet above.

The first thing a REST Client needs in order to function properly is the full URL path of the type of request it is making and the route it is trying to access. In this case, the request is POST, the URL is http://localhost:3003/registerUser. HTTP/1.1 at the end of the first line relates to the standard established by RFC 2616, but I’m not sure if it’s necessary, so I’ll keep it just for security.

Then, because this is a POST, include a JSON body in the request, noting that there is a blank line between the content-type and the body — this is what the REST Client wants on purpose. So, we fill in the required fields, and there should be a little send Request option above POST. Put your mouse over it and click and see what happens.

The last thing you need to notice is the ### after the request in the test.http file. This is the separator between requests, and you can include any number of requests in the file by inserting ### between each request.

If the request is successful, you’ll see something similar to what I posted above. Even if the request is unsuccessful, you still get all this information about what just happened and (hopefully) what went wrong. Great!

GET the sample

Now you’ve created a user, let’s say we forgot their password, and they send an email to get it back. The email contains a token and a link that takes them to a page to reset their password.

Once they click on the link and log on to the page, a GET request is launched to ensure that the token included in the email for resetting the password is valid, which is what it might look like.

My GET points to the /reset endpoint and appends the resetPasswordToken query parameter on the server side for validation. The content-type is still Application /json, and the ### at the bottom separates this request from any other requests in the file.

If the token is indeed valid, the server responds as follows:

And that’s all they need for a GET request; they don’t have to worry about the body of the request.

The Update sample

Next comes the U in CRUD: Update. Suppose a user wants to update something in their profile information. Using the REST Client is not difficult either.

For this request, the request type is updated to PUT, and the body includes any fields on the object that need to be updated. In my application, users can update their first name, last name, or email.

So this is what the Response TAB in VS Code looks like if the REST Client successfully hits the PUT endpoint when the body is passed.

With that said, let’s continue with the authentication example. Because as far as I know, there are very few applications that don’t have secured routing and require some kind of authentication.

The Authentication example

Again, I was impressed by the breadth of the different authentication formats that REST Clients support. At the time of this writing, the DOCUMENTATION for the REST Client states that it supports six popular authentication types, including support for JWT authentication, which my application relies on for all protected routes.

So, without further ado, here’s one of the endpoints I need to validate: looking up the user’s information in the database.

Adding authorization to a REST Client request is really simple: Simply add the key Authorization below where the route and content-type are declared, and then (at least in my case) I add the JWT keys and values (because they appear in the browser’s local storage) as the values of the Authorization header.

So it becomes:

Authorization: jwt XXXXXXXXXXXXXXXXXX
Copy the code

Then just send the request and see what happens.

If your authentication is configured correctly, you will receive some type of 200 response from the server, which, for my request, will return all the information about the user stored in the database, as well as a message that the user was successfully found.

This part may require some trial and error, but it’s well worth it if you can figure out how a successful request is made in the browser’s Dev Tools network call, through an existing Swagger endpoint, or through other similar documents.

DELETE the sample

After the other examples I provided above, this example should be simple

The query parameter for this DELETE is username, so it knows which user in the database is being deleted, and it also needs to verify that the user is qualified to make the request. Beyond that, there is nothing new to introduce here.

This is really just the tip of the iceberg of what REST clients can do. I’ve covered REST requests and one form of authentication, but it can also support GraphQL requests, many other types of authentication, environment and custom variables, viewing and saving raw responses, and more.

I highly recommend that you review the documentation to understand all the capabilities of the REST Client, which is very powerful.

REST Client documentation: marketplace.visualstudio.com/items?itemN…

The end of the

Data drives the Internet, and Web developers eventually become very good at accessing and transforming data to suit their needs as their career progresses.

In the past, Web developers often turned to tools like Postman or Insomnia to have a slightly better interface than the command line when getting data hosted elsewhere, but now there’s a VS Code plug-in that makes requirements outside of the Code editor a thing of the past, called the REST Client, Very good.

CRUD operations? No problem! Support GraphQL? No problem! Authentication options? No problem! The REST Client provides all of these options and more, and is simple to set up and use. I will definitely use it more in future projects.

Check back in a few weeks — I’ll be writing more about JavaScript, React, ES6, or anything else related to Web development.

Thanks for reading. I hope you’ll consider using the REST Client to handle any API queries you might need to do in the future, and I think you’ll be surprised at how pleasant an experience it can provide, without any API GUI required. 🙂

Original text: blog. Bitsrc. IO /

By Paige Niedringhaus