Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please add instructions (or a FAQ) how to (easily) migrate from „REST Client"-extension“. #266

Open
ipalfy opened this issue Mar 9, 2024 · 4 comments

Comments

@ipalfy
Copy link

ipalfy commented Mar 9, 2024

Ok, just the basics ...

While both work, even together, I want to migrate all my „REST-client"-files to httpyac.
many questions arised though, and I still don’t understand how to insert variables from env files.

Also I never got variables completion to work.

@ipalfy ipalfy changed the title Please add instructions (or a FAQ) how to (easily) migrate from „rest-extension“. Please add instructions (or a FAQ) how to (easily) migrate from „REST Client"-extension“. Mar 9, 2024
@ipalfy
Copy link
Author

ipalfy commented Mar 10, 2024

Reading the docs (in every detail) was actually helpful. 😬

  • Had to understand the global section (everything before the first ###) - only those variables are global, so available for all other requests. Nice: codelens „execute“ for sections without requests.

  • Important: Had to add codelens „validate vars“ in the request. This way you always know, which variables are available

  • Very nice: Test explorer integration.

in fact httpyac is extremely powerful. Also tried listening to EventSource with multiple message types, very helpful.

@AnWeber
Copy link
Owner

AnWeber commented Mar 11, 2024

I'm glad you've made some progress.

Had to understand the global section (everything before the first ###) - only those variables are global, so available for all other requests. Nice: codelens „execute“ for sections without requests.

Not quite. All regions that have no request or name.. Order is not important

Also I never got variables completion to work.

Sorry, but does not exists. By using Javascript as a variable provider, I would have to have some kind of parser for Javascript for full code completion. The whole topic is too complicated/ time consuming for me to implement and that's why the workaround with the display of the variables.

Differences to vscode-rest-client

Unfortunately, there are deviations, especially when accessing the response object:

  • reference regions uses other interface and there will be some breaking changes
    • reference regions use object with request and response. I directly reference the response
    • no JSON Path or XPath support (use Javascript access with response.parsedBody instead)
  • no support for $dotenv. just use variables directly
  • no explicit Azure AD ($aadV2Token) support but should be replaced with OAuth2 Provider
  • GraphQL does not filter the special GraphQL Header

I think that should be all the missing features, but no guarantee. You could support vscode.rest-client 100%, but that wasn't important to me after a certain point.

in fact httpyac is extremely powerful. Also tried listening to EventSource with multiple message types

I wanted to see when my tool would break and how good my inital architecture concept was, and I looked for use cases that I hadn't initially considered. You notice the rough edges (code completion, formatting, no browser support), but in principle it works well. Just let me know if I can help

@ipalfy
Copy link
Author

ipalfy commented Mar 11, 2024

Everything’s is fine, and thanks for your detailed explanation!

Your initial concept is great, rest-client compatibility isn’t really needed.

Variable completion might be „nice“, but not essential. I was just wondering - so it might be good enough to just mention it in the docs.

And since I am currently migrating parts of our „testing“ to httpyac, I will also write some „onboarding“ steps for my colleagues. I might also add some best practices and additional instructions, so we can all use both, httpyac and httpbook in our http directory, also containing all relevant .env files for this purpose.

If you are interested, I can send you the readme.md you could also use as a „Getting Started“ section in your docs. (If it’s accurate enough and if I am finished)

Since I also (mostly) use .http files to test third party APIs (like Sendgrid, the mongoDB atlas api and slack) I could also contribute them to your examples. I would also suggest to add a Note in the docs: „Please contribute your third party .http files“.

interestingly I just accidentally found out you have a httpyac item in the vscode activity bar, which turned out be be quite useful but it’s undocumented.

in fact there are many (very minor) issues that could be addressed, especially when using httpyac and httpbook together. Fixing these should be easy but effective, so it could „just work“ even for those lazy guys like me how don’t want to read too many docs.

While I was quite happy with the rest-client extension (compared to postman) the author seems to have not enough time or need to continue its development. There are even 5? forks with very minor improvements. So httpyac is the best possible replacement.

BTW: If you wanted to make your extension „fly“ you could contact one of those YouTubers or even the vscode team to make a short video. The rest-Extension has over 4 million downloads, yours only 35K. Even though httpyac is far ahead! Actually vscode could profit the most!

@ilengyel
Copy link

no JSON Path or XPath support (use Javascript access with response.parsedBody instead)

Actually xpath works for me maybe you added this recently?
@state = {{$xpath:first //input[@id='__SOMESTATE']/@value}}

no support for $dotenv. just use variables directly

The following also works for me {{$dotenv SOME_KEY}}, when I choose to keep the $dotenv marker to illustrate the source of the variable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants