As developer, we are using tools to make REST API calls (Postman, Insomnia, PostWoman...), and these tools are very usefull.
The limits
Make calls to test an API is fine, but if you want to edit, version, or simply share it with your team ... it's not very handy.
Indeed, you can use Postman paid plans for instance, but it means that you need to pay, and it means that all your team needs to use Postman, again one more tool...
Do you know REST Client ?
REST Client* is a VS Code extension.
It will let you to send HTTP requests and view responses into VS Code. And only based on a text file, which can easily be versioned among your repository. đ
Pros
The main advantage is to be able to version and share your API calls.
If you're working on an internal API, you may want to share how to test a new endpoint with your colleagues.
REST Client is a good easy way to do it !
Another good point is simplicity. All you need to do/have, is ONE file. Also, if you jump between projects and do not remember how works an API/Service on which you did not work since a while, just look at this file !
Cons
You have to use VS Code... but for a lot of known reasons among internets, you are using Emacs, VI, or VS Code đ
What's next ?
Here is how to begin.
The file
Only create a file with .http extension, for instance doc.http
And then, VS Code will show you the file as :
And by clicking on "Send Request", a new tab with all request response details will be opened.
Go further
You may also use environment variables to easily switch between you env and avoid any api-key or token manually update in the file, or url update etc...
Here is how to use environment variables, just like that :
Here, I created 4 environments : local, dev, staging, production.
These 4 environments have their own host and token variables, with their specific values.
But they also share a variable, named partnerUniqueToken (don't ask me why ... too many partners don't have several env...).
Hope it helps !
Top comments (113)
Thank you for the article and opening this topic. I been using this feature in JetBrains products for some time. It's a great tool for helping you in local development. Also having an ability to create .http files and store them as part of your CVS and share it with your team is a great benefit. There is a great hidden potential in .http files.
But there are some problems concerning cross tooling compatibility and integration. The concept actually has a name: HTTP Request in Editor Specification. This name is shared by both JetBrains and VS code extensions (partially in form of HTTP Request in Editor) respectively. JetBrains went a step further and created a actual RFC specification strictly based on RFC 7230. VS code extension claims to be based on RFC 2616 which has been obsoleted by RFC 7230 some time ago. So you can have possible problems when created files in VS code and running in them in JetBrains. Both extensions claim to support .http/.rest file extension, but IMHO .http file extension should be used exclusively because .rest can be confused with Docutils reStructuredText Document.
There is also an important question of validation and testing. JetBrains extension supports Response Handlers which can intercept the HTTP Responses, validate and assert them. They can be written in ES5 (JavaScript). These Response Handler files can live along with .http files and make sure when somebody is using those file to make HTTP requests he gets expected response. The only problem is that you have to run .http files (with Response Handlers) in JetBrains IDE. So far I haven't found a library that could run the .http files with Response Handlers via CLI. If there was such a library it would allow us to run API tests based on .http files on CI (good idea for opensource project:) and verify .http files against my API. It would also allow running .http files for people not using JetBrains or VS code IDEs.
So I think there is a great potential in this, and the community can fill some gaps that will allow us to utilize HTTP Request in Editor Specification into it's full potential.
Can HTTP Request in Editor Specification replace Postman? I don't think so, at this point in time. But in future, with more tools, integrations and libraries? I'd say: yes, very possibly.
HTTP Request in Editor specification (by Jetbrains): github.com/JetBrains/http-request-...
RFC 7230 - tools.ietf.org/html/rfc7230#sectio...
RFC 2616 - w3.org/Protocols/rfc2616/rfc2616-s...
Implementation of the spec in mainstream languages: github.com/JetBrains/http-request-...
JetBrains HTTP Client documentation: jetbrains.com/help/idea/http-clien...
Rest CLIENT VS extension: marketplace.visualstudio.com/items...
CLI runner for HTTP Request in Editor jetbrains issue: youtrack.jetbrains.com/issue/WI-42002
Thanks a lot @char0n for this whole comment, terribly interesting !
As I found out today JetBrains has actual plans to implement a runner for the spec: youtrack.jetbrains.com/issue/WI-42002
Fantastic comment, very insightful
Many thanks @ankush981, indeed, probably one of the best reason : "why open another RAM-hungry app" !
For Peter Edwards...
Some unfortunate souls are forced to work with underwhelming equipment that benefit from not having yet another tool running. Regardless of capacity... My personal stuff runs circles around the dev env I have to use for work. Everything I can do with something like VS code I do to make that work system at least usable....
Even if iâm not forced (i could easily afford expanding my RAM), some simply doesnât want to. I refuse to buy RAM just to run another RAM-hogging app (most probably a âDesktop Appâ built on Electron) and will use a less RAM-demanding, actually native program. If there is none, i need to be really interested in the platform to put some money in using it (not the case most of the time).
So please, optimize for RAM. Even with todayâs tech like SSD drives and such it worth it.
Ram-hungry? Equipment is cheap compared to salaries these days running out of ram should just not happen even with swapfile disabled
Maybe some people play games while building the app and testing lol
It's more like a mind-set, I don't want to have "one more" app launched. We all already have IDE, Chrome, Sequel, Slack, Trello, Terminal ...
Yeah, lagging will mess my mood. if it's not 60fps then I'll not code hahaha just kidding đ
Meh, Postman is still better than this in my humble opinion. They're making you pay for a good reason. I'm getting old, I want a nice an intuitive interface. I pay to save my time and Postman is really helping with this.
EDIT: I just tested it, still a big MEH. Not sure how big your projects are but I feel this is not suitable for the size of my projects.
We have a lot of REST APIs to test, as well as a lot of variables that need changing on the fly quickly by testers to test certain scenarios. For us, Postman works better. This plugin is ok but we have powershell scripts that can do the same stuff and its not as intuitive.
I get the idea behind this in that it just "fits" into version control etc and in theory its easier to have VSCode installed, but I think there is space for both of these tools. This extension fits nicely for quick dev test stuff, but I think I still prefer Postman for more complex scenarios, plus it has a host of other features.
Hmm, if it fit you and your team organisation, it can be a solution, for sure :) We're trying here, to avoid to get thousands of tools and be sure to be up to date with "just the repo".
You must be doing a lot. I use a lot of tools too (I work fully digitally), but I close the ones I don't use right away.
Some ones are always opened you know (IDE, Slack, Database connection, Terminal, Trello, Chrome etc..) hard to be able to close each tool one you're done with.
That's really not a lot. And that's about all I need as a fullstack developer. The terminal is part of VSCode and I use pen and paper for my tasks (with ClickUp for project management). I don't use any messaging app WHILE coding, no distractions.
Even tho I dabble with many parts of the systems I maintain and build, I don't have more than 6-8 apps open at the same time. And this is not even half of the apps I can handle open at the same time.
I feel like we're bringing a problem that does not exist just to justify the use of this tool... and I feel like a hater, so I'll stop at this. ;) I hope it's useful to anyone else. I'll try to get more invested into testing it out in the future.
Is there a version of this for Jetbrains??
Hi @alejandrorios ! Did you already check jetbrains.com/help/idea/http-clien... ?
đź I didn't know it, thanks
đȘ
It's nice but one thing to consider. You can share the whole workspace of postman either with a single person or with a team, your choice. I think that reduces the pain of editing the source code or it's syntax maybe.đ
Hi @mohdraqif1 . Yes, you're right, but by putting it into your repo, you can be sure that it's always up to date :) I think that we should never be afraid of updating code/repo.
If we're afraid, it may mean that we are not confident :)
Another addition is our project: Postwoman.io - Online API request builder.
GitHub: github.com/liyasthomas/postwoman
Hi @liyasthomas , It let you save everything in a file that you can share with your team and version into the project repo ?
ps : but believe me, it's on my favorite (from the time where favicon was an Alien head ;) ) and I often use it !
Versioning and saving to GitHub repo will be the perfect option :) can not wait to see it !
On it. đđ
Maybe let the Alien face as favicon come back, I have so many favorites but this one, I saw it first each time ^
Will consider that â€ïž
đ
"Versioning and saving to GitHub repo - Work in progress"
Didn't see an issue to follow for this. Is it complete now? Thanks
Holy balls this is awesome! I'm working solo at the moment so keeping Postman up to date has been at the absolute bottom of my priority list... My workspace already has 5 necessary windows up(VS, Server console, Code and Chrome) and having to switch between them is already a nightmare without introducing Postman to the mix.
Being able to test the API without leaving Code would be a godsend! Damn am I happy your article showed up in my feed, thanks a googolplex! I didn't even think about using something other than Postman.
Hi @thebojan , that's a limit we had with Postman and its workspace... Very happy that we can help you :)
Ford development that is great, but as a generic tool, Postman can export/import curl calls that can be copy/paste to and from terminals
Also, can the env vars be used to parameterize the actual content of the requests? How can certificates be configured?
Yes it's true that the ability from Postman to generate the command for cURL, Node, PHP, Ruby, Python can be very usefull !
Yes, Auth via SSL Client Certificates is support :)
I am getting below error while posting the call
write EPROTO 1215459160:error:100000f7:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER:../../third_party/boringssl/src/ssl/tls_record.cc:242:
Check if u not trying to call yr API using
httpswhen it supportshttpthank you
Are you using https instead of http? Maybe this is the problem
Try to use http after your request. e.g GET localhost:3000/articles HTTP/2.0
I have the same error until i use this.
thank u
Looks like it come from API you're trying to call no ?
REST Client is such a great tool. We using extensively for the purpose of testing, and sharing examples in our project repos.
The ability to use JSONPath to follow links or grab values from your API response to form the next request is invaluable. Not to mention really great for demonstrating how REST APIs are meant to look and work!
If you've not tried it, give it a go. You need to name your request with:
# @name MyAwesomeRequestBut then once you've invoked it you can access a variable of the same name so
{{ MyAwesomeRequest... }}the request and response plus the headers and body for both.It's only more recently I stumbled across the environments feature, but that's made a huge difference in cutting down the noise of declaring loads of variables that change per environment.
Hi @devjonny !
Totally agree, grabing values from previous API responses is amazing and let you easily test calls sequences.
Many thanks for this sharing, hope it could help readers to deep dive on this such great extension !