This is DEAD. Ask for new maintainers

[fatso83]

Hi, this tool is pretty well spread, but there is no activity. You should ask for new maintainers in the README or just archive the repository if it is dead.

[marcellourbani]

Up
and maintainer has gone AWOL. I think we should start an organisation and fork it

[olimaryou]

Just use httpyac, vscode extenison here https://marketplace.visualstudio.com/items?itemName=anweber.vscode-httpyac
It's far superior, well documented, with many more features and with a CLI for automation (CI/CD for example)

[BAVhel]

Just use httpyac, vscode extenison here https://marketplace.visualstudio.com/items?itemName=anweber.vscode-httpyac It's far superior, well documented, with many more features and with a CLI for automation (CI/CD for example)

yes, but the last commit was 7 months ago(Apr 6, 2025)

[ppanchal-mobiz]

This seriously needs to be looked into. One of the Microsoft Azure's extension vscode-apimanagement has a dependency on this extension https://github.com/microsoft/vscode-apimanagement/blob/2450924815c63647fad6bb34e0f3be894c663c56/package.json#L1045

[tutilus]

Hello @marcellourbani Hello,

At the beginning of this year, I forked the repository because I found this plugin very interesting and I've use it frequently, but I wanted to ensure I could keep using it with at least a minimum of maintenance.

So, if you're interested, it is available here: https://marketplace.visualstudio.com/items?itemName=tutilus.rest-client-next. I have merged a few PRs to fix some issues, and my main focus is keeping the dependencies up to date.

I quite agree with @olimaryou that httpyac adds some very interesting features to go further. However, I really like REST Client just the way it is, so :)

[marcellourbani]

Thanks @tutilus , we really needed a maintainer
httpyac is way more powerful, but makes hard things possible and easy ones complicated

I liked the organization idea better, but as a maintainer it's definitely your call

[TecniartGalicia]

other maintained fork, for anyone weighing options in this thread: HttpKeeper (https://github.com/TecniartGalicia/httpkeeper - argalla.httpkeeper on the Marketplace and on Open VSX, so it installs in Cursor and VSCodium too).

@tutilus's rest-client-next and this one started from the same place, and I would rather join forces than split the users. @marcellourbani's organisation idea is the right one; I am in if you both are.

What HttpKeeper has done so far, in case it is useful to either fork:

• A test suite: 37 tests against a real local server. The original had none, which is why the 61 open PRs were never safe to merge.
• Production dependencies at 0 vulnerabilities (from 75). aws-amplify - the whole AWS SDK - was pulled in for a Cognito login; it is now a small HTTP client, 1,088 packages gone. Telemetry removed.
• PRs fix: response preview not shown when viewColumn is undefined (Cursor) #1440 (the Cursor fix, Expriencing Issue on Cursor #1434), fix: handle Readable stream body and avoid mutating original headers in AWS signing #1432 and Support multiple values for JSON PATH #853 merged after testing them; Fix IPv6 Support for Localhost #1396 and feat: Eval system variable #532 rejected, with the reasons written down.
• The three most-voted requests here implemented: How to write tests on top of the requests? #267 assertions in the file, Sequential execution of multiple requests. #724 / Send all requests in a file #444 running a whole file in order with chained variables, and Cli runner for the same format #432 a CLI runner with exit codes for CI.

Same .http format, rest-client.* settings still read, same ~/.rest-client folder: switching in either direction costs nothing.

Huachao's copyright and MIT license are kept, and everything is offered back upstream.

[tutilus]

Hi @marcellourbani and @TecniartGalicia,

I am completely open to the idea of an "organization". I wasn't really aware of this possibility and I am not really attach to have my own "rest-client" :)

I created this fork mainly because I wanted to keep using this very useful plugin—as I guess you did too, @TecniartGalicia —and I needed it to be up to date (especially in regard of the vulnerabilities).

I used the fork to modernize it a bit (adding CI/CD workflows, splitting the README into proper documentation), reducing the size of the plugin, picking a few PRs I found useful for my needs, and fixing some UX behaviors (I think there is work to do to improve syntax colorization).

Anyway, if there is a better and more sustainable approach, as long as we keep it compatible and aligned with what @Huachao did, I'm all in.

[marcellourbani]

@tutilus @TecniartGalicia I created an organization and invited you guys
I plan to make you both admin once you accept, happy to hand it over if you want to be in charge
Later today I'll create a vscode-restclient repo based on either of your forks, or perhaps a mixture, and try to set up vscode publishing

I won't have much time to maintain this, but will be a step forward from this dead repo

[marcellourbani]

@tutilus @TecniartGalicia I created a repo too
Have yet to decide which fork to use as a base, asked an AI to evaluate pros and cons
Will start an issue to discuss it in the new repo once you guys joined the org

[marcellourbani]

Actually I realize only now that while tecniart's is a proper fork, tutilus's repo have an independent history
This makes @TecniartGalicia's way more attractive. Still thinking anyway
The move to jetbrains format and removal of all documentation from README make me a bit hesitant: I know nothing about jb format and how much will break compatibility

[TecniartGalicia]

Thanks @marcellourbani — invitation accepted, and count us in as maintainers, not just as a base.

On your two hesitations, with facts rather than promises:

Compatibility. The JetBrains support is additive: every REST Client file runs unchanged. Nothing was removed or renamed in the format, rest-client.* settings are still read, and history/cookies/environments come from the same ~/.rest-client folder. What was added are things that did not exist before (http-client.env.json, import, run #name, {{$secret}}, # @assert, WEBSOCKET, text/event-stream painted live) — a file that does not use them is not affected. The 52 tests include 28 integration tests that send real requests through the extension against a local server, most of them written to pin REST Client's existing behaviour (variables, environments, redirects, cookies, localhost/IPv6, JSONPath/XPath request variables) before touching anything. The two upstream PRs I rejected were rejected because they broke compatibility (#1396 broke localhost) or safety (#532 ran shell commands from the file).

Documentation. You are right that the README became a pitch. Huachao's full reference is now back, verbatim, in docs/REFERENCE.md, and the README links to it. If the org prefers it as the README itself, that is a five-minute change.

For the org repo, my proposal: base it on HttpKeeper's master (proper fork, history intact, CI on three OSes, 0 vulnerabilities, release workflow that publishes to the Marketplace, Open VSX, npm and GitHub in one tag), and graft what @tutilus did that we lack — the CI/CD and docs split, the UX fixes and the syntax-colouring work. I am glad to open that as PRs against the org repo once it is bootstrapped, and to keep maintaining there. Publishing identity (which publisher, whether argalla.httpkeeper stays as the published build or we move to an org publisher) is worth its own issue; I have no attachment to the name, only to not stranding the people who already installed.

Whatever base you pick, keep Huachao's copyright line and the MIT text as they are in our LICENSE.

[TecniartGalicia]

For the base decision, here are the numbers rather than opinions. I cloned the three repositories today and ran the same checks on each (git log, npm audit --omit=dev, test count, CI files, store listings). Corrections welcome — @tutilus, please fix anything I got wrong about yours.

	Huachao/master (the org repo today)	tutilus/vscode-restclientnext	TecniartGalicia/httpkeeper
Git history	original, 840 commits	independent: 146 commits since 2026-02-19 ("init yeoman vscode"), none of the original commits	original 840 + 35 on top; every upstream commit still attributable
Tests	0	8 (vscode-test, 175 lines: variable regex, auth headers, proxy mapping)	52 (24 unit + 28 integration that send real requests through the extension against a local server, incl. SSE and a WebSocket echo)
npm audit --omit=dev	75 vulnerabilities (6 critical)	3 (2 high, 1 moderate)	0
Production packages	1,487	236 (aws-amplify still in)	399 (aws-amplify replaced by a 60-line Cognito client)
Telemetry	Application Insights	removed	removed
CI	Node CI from 2019 (broken)	CodeQL + release (vsce); no test job	tests on Linux/macOS/Windows; release publishes Marketplace + Open VSX + npm + GitHub from one tag; the built .vsix is installed in a clean VS Code and exercised in CI
Upstream PRs handled	61 open	6 merged (#1422 @set, #1388 run all sequentially, #1104, #1356, #1380, #1381)	3 merged after testing (#1440 Cursor, #1432, #853); 2 rejected with written reasons (#1396 broke localhost, #532 ran shell commands from the file); 52 conflict, triaged in docs/PRS-REVISADOS.md
Most-voted requests	—	run all sequentially (#1388)	#267 assertions, #724/#444 run a whole file with chained variables, #432 CLI runner, #229/#627 env files, #182/#845/#1148 import/run, #279 secrets, #493 SSE live, #173 WebSocket
Compatibility	—	preserved (stated goal)	additive only: REST Client files, rest-client.* settings and ~/.rest-client untouched; 28 integration tests pin the inherited behaviour
Docs	README	Jekyll docs site, 9 pages (nice)	README + Huachao's full reference verbatim in docs/REFERENCE.md
Minimum VS Code	1.81	1.106	1.81 (newer APIs — LM tools, MCP — are guarded at runtime)
Published	humao.rest-client, 2022	tutilus.rest-client-next, Marketplace only, 30 installs	argalla.httpkeeper on Marketplace and Open VSX (Cursor/VSCodium), httpkeeper-cli on npm, GitHub Action
Credit to Huachao	—	yes, README	yes: README, CHANGELOG, contributors, LICENSE line kept

kit1211's cursor-rest-client-plus (Open VSX only, 1,547 downloads) is worth a mention too: its Cursor fix is the PR we merged (#1440), and its response-tab reuse and {{$faker}} would be good contributions to whichever base wins.

What I would take from this: the org repo should have the original history (so Huachao's work stays his in git blame and any future upstream merge is trivial), tests before merges, and a release pipeline that reaches the editors people actually use. HttpKeeper has those today; rest-client-next has the better documentation site and a cleaner dependency story on engines. So my proposal is: base = HttpKeeper's master pushed as-is (git fetch https://github.com/TecniartGalicia/httpkeeper master && git push origin FETCH_HEAD:main, five minutes, no rewrite), then tutilus's docs site and UX work grafted on top as PRs — I am happy to do that grafting myself if @tutilus prefers to review rather than port.

Naming and publishing identity deserve their own issue; I have no attachment to "HttpKeeper", only to not stranding anyone who already installed any of the three.

[tutilus]

Wow, incredible responsiveness @marcellourbani! Thank you very much. I've accepted the invitation as well.
I am glad to start this adventure.

It's really interesting to see both repositories summarized like this.

I agree with the conclusion to start with @TecniartGalicia's repo as a base and add what's different in mine. I'm not sure I'll have time to port it over quickly, so if you want to do it, be my guest @TecniartGalicia. I will try to find time, but it would be easier for me during the winter season.

Speaking of naming, having a discussion about it seems like a good idea. In my opinion, keeping the original name (or something very close) sounds important if we want to honor the legacy of the project.

[TecniartGalicia]

Thank you both — that was quick. Then let's make it concrete, in the org repo rather than in this thread:

1. Base. With your go, @marcellourbani, I push HttpKeeper's master to vscode-restclient/vscode-restclient as main, history intact (no squash, no rewrite). One command, reversible, and from then on all work happens there. I will not touch the org repo before you say yes.
2. Porting rest-client-next. I take it, @tutilus — thank you for the trust. I will open an issue there listing what yours has that we lack (the docs site, the syntax-colouring work, the UX fixes, @set from Add @set directive for cross-file shared runtime variables #1422, and anything you point me to) and port it in small PRs you can review at your pace; winter is fine for the review, no need to port anything yourself.
3. Name and publishing. Agreed that the name should honour the legacy. Two constraints worth knowing before that discussion: the Marketplace ID humao.rest-client belongs to Huachao and cannot be reused, so the org needs its own publisher; and the Marketplace rejects names it considers too close to an existing extension, so "REST Client" as a display name under a new publisher may or may not pass — I can test it with a private listing before we decide. I will open a second issue for this so it gets its own thread. Until the org publishes, argalla.httpkeeper keeps shipping the same code from the org repo; when the org listing exists, ours points people to it.

If that plan is fine, say so and I start with (1) and the two issues today.