VS Code’s REST Client Plugin is All You Need to Make API Calls

Why leave the IDE to test new endpoints? Now you don’t have to.

Paige Niedringhaus
Bits and Pieces

--

Photo by Carlos Muza on Unsplash

Web Developers fetch a lot of data

If you’ve been doing web development for any length of time, you’re probably aware that a lot of our job revolves around data: reading data, writing data, manipulating data and displaying it in the browser in a way that makes sense.

And the vast majority of that data is supplied from REST API endpoints: representational state transfer application programming interfaces (what a mouth full 🥵, hence REST API). In laymen’s terms: the data we want exists in some other service or database, and our application queries that service to retrieve the data and use it as we see fit.

Now in the past, in order to test REST APIs before wiring up the UI to accept the data, typically you’d have to either query the API through a terminal’s command line, or use a GUI like Insomnia or Postman (which I actually compared in a previous blog post).

But now, if you use VS Code (and why wouldn’t you, it’s so nice to write code in!) life has just gotten simpler. No longer do we need to exit the IDE to test APIs, because now a plugin exists to do just that: REST Client.

The best part? Getting started with REST Client is incredibly simple, and I’m going to show you just how easy (and full featured) this plugin is, right here, right now.

Let’s get started.

💡 Tip: If you needed to reuse components across multiple projects, you can do so using OSS tools like Bit.

Bit (GitHub) makes it simple to share, document, and organize independent components from any project.

Use it to maximize code reuse, collaborate on independent components, and build apps that scale.

Bit supports Node.js, TypeScript, React, Vue, Angular, and more.

Learn more here:

Example: exploring reusable React components shared on Bit.dev

Meet the VS Code REST Client plugin

I’m a fan of VS Code as a code editor, and have been for a number of years now, and every time I learn about a new useful plugin someone has created and added to the VS Code marketplace, I am immensely grateful for it.

So when I decided it was a pain to have to fire up Postman or Insomnia every time I needed to test a new API route, I found out about REST Client, the plugin that makes that unnecessary.

REST Client has the most obvious name for a tool that’s ever existed and its VS Code marketplace description sums up exactly what it does: “REST Client allows you to send HTTP request and view the response in Visual Studio Code directly.”

It’s that simple. It’s then followed up with a healthy dose of further information and examples of how to use it, but in essence, it’s an HTTP tool built in to VS Code. So let’s get to using it.

Install REST Client

Step 1: Install REST Client in your VS Code.

To find it, open the marketplace extension in VS Code (the little Tetris blocks icon on the left panel), type “rest client” into the search bar, then install the first result in the list (the author should be Huachao Mao).

Here’s a screenshot so you know you’ve gotten the right one.

Screenshot of VS Code with REST Client plugin pulled up in VS Code marketplace.

Once it’s installed, we can move on to setting it up.

Set up a REST Client Script

Step 2: Create a .http file in the root of your project folder.

This step actually sounds more complicated than it actually is. Simply create a file at the root of your project that ends in .http. REST Client recognizes this and knows it’s supposed to be able to run HTTP requests from this file.

When I was testing this out, I took a dockerized full-stack MERN login app I made a few years ago, and dropped a file I named test.http into the root of the project folder.

Image of folder structure opened in VS Code and the new `test.http` file inserted right at the root of the repo.

Test it out

Step 3: Make some different routes and run them.

This is the part that’s cool: in my experience this little REST Client plugin was able to do just as much as the more sophisticated API clients like Postman.

Below, I’ll show you to do each type of basic CRUD operation, plus how to make API calls requiring authentication like a JWT token, using my locally running MERN user registration app to point the calls towards.

POST Example

The first example I’ll cover is a POST with REST Client, because with my application a user must first register before they can do anything else (it’s just a login service, after all).

So here’s what that code will look in the test.http file.

Snippet of code for making a POST request using VS Code’s REST Client plugin.

Ok, let’s go over what’s happening in the code snippet above.

The first thing REST Client needs in order to work, is the type of request to make and full URL path for the route its attempting to access. In this case, the request is a POST and the URL is http://localhost:3003/registerUser. The HTTP/1.1 at the end of the first line has something to do with the standards established by RFC 2616 but I’m not exactly sure if it’s necessary or not, so I left it there just to be safe.

Then, since this is a POST, there’s a JSON body to include in the request, note that there’s a blank line between Content-Type and the body — this is intentional and required by REST Client. So we have the required fields filled out, and then, above the POST a little Send Request option should appear. Mouse over it and click, and see what comes back.

The POST request I sent through VS Code on the left, and a second panel that opened on the right to show me the response.

The last thing you’ll want to note is the ### after the request in the test.http file: this is the separator between requests. You can have as many requests in the file as you like as long as you throw ### in between each request.

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

GET Example

Now that a user’s been created, let’s say we forgot their password and they send an email to recover it. The email contains a token and a link that will take them to a page to reset their password.

Once they’ve clicked the link and landed on the page, a GET request is fired off to ensure the token included in the email to reset their password is valid, and this is what it might look like.

Example of a GET request in VS Code’s REST Client.

My GET post points toward the /reset endpoint and tacks on the resetPasswordToken query parameter required to validate it on the service side. The Content-Type is still application/json and the ### at the bottom separates this request from any other requests in the file.

The response from the server, if the token is indeed valid looks like this:

GET request response from server for a valid password reset token.

And that’s all that’s needed for GET requests. They don’t have request bodies to worry about.

Update Example

Next up is the U in CRUD: update. Let’s say the user wants to update something in their profile info. Not hard to do with REST Client either.

Example of a PUT request in VS Code’s REST Client.

For this request, the request type is updated to PUT (no pun intended 😅), and the body includes any fields that need to be updated on that object. In my application, a user can update their first name, last name or email. If they want to update their password, that’s a separate screen and route because the password is encrypted and hashed once it reaches the database, never to be unencrypted in the browser again.

So, when the body is passed, and REST Client hits the PUT endpoint, if it succeeds, this is what the Response tab in VS Code will look like.

PUT request response from server for valid update of user information.

And now that that’s covered, let’s move on to the authentication example. Because there’s very few apps I know of without protected routes that require some sort of authentication.

Authentication Example

Once again, REST Client impresses me with the breadth of different auth formats it supports. At the time of writing this, REST Client’s documentation says it supports six popular types of authentication, including support for JWT authentication, which is the type of auth my app relies upon for all its protected routes.

So without further ado, here’s one of my endpoints requiring auth: looking up a user’s info in the database.

Example of an HTTP request in REST Client that requires JWT authentication.

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

So it becomes:

Authorization: jwt XXXXXXXXXXXXXXXXXX

Then just send the request and see what happens.

Successful GET response requiring JWT bearer token authentication to access a protected route.

If your auth is configured correctly, you’ll receive some sort of 200 response from the server, and for my post, it returns all the information associated with this user stored in the database, plus a success message they were found.

It may take a little trial and error to get this part right, but if you can figure out how a successful request is being made in the browser’s Dev Tools network calls, via an existing Swagger endpoint, or with documentation from others doing something similar, it’s well worth it.

Delete Example

Last but not least, the DELETE action. So long user information. This should be pretty self explanatory after the other examples I’ve provided above.

Example of a DELETE request in REST Client.

This DELETE needs a query parameter of username so it knows exactly which user to delete in the database, and it also requires authentication that this user is qualified to make this request. Besides that, there’s not much else new material here to cover.

When a user succeeds in deleting their profile from the database, the database logs out that it’s done.

And this is really just the tip of the iceberg of what REST Client can do. I covered REST requests and one form of auth, but it can also support GraphQL requests, multiple other types of authentication, environment and custom variables, viewing and saving raw responses and more.

I strongly encourage checking out the documentation to see what all is possible with REST Client; it’s quite robust.

Conclusion

Data drives the Internet and web developers end up getting very adept at accessing and transforming it to suit their needs, the further they progress in their careers.

Previously, when fetching data hosted elsewhere, web developers often turned to tools like Postman or Insomnia to have a slightly nicer interface than the command line, but now there’s a VS Code plugin that’s made the need to go outside of the code editor a thing of the past. It’s called REST Client and it’s great.

CRUD operations? Check. GraphQL support? Check. Authentication options? Double check. REST Client provides all these options and more, and it’s dead simple to setup and use. I’m definitely going to be using it more in my own projects going forward.

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

Thanks for reading. I hope you’ll consider REST Client for any future API querying you may need to do, I think you’ll be pleasantly surprised at the enjoyable experience it can provide, no API GUI required. 🙂

If you enjoyed reading this, you may also enjoy some of my other free pieces:

Build Apps with reusable components, just like Lego

Bit’s open-source tool help 250,000+ devs to build apps with components.

Turn any UI, feature, or page into a reusable component — and share it across your applications. It’s easier to collaborate and build faster.

Learn more

Split apps into components to make app development easier, and enjoy the best experience for the workflows you want:

Micro-Frontends

Design System

Code-Sharing and reuse

Monorepo

References & Further Resources

--

--

Staff Software Engineer at Blues, previously a digital marketer. Technical writer & speaker. Co-host of Front-end Fire & LogRocket podcasts