![]() That said, here are some additional thoughts (both positive and negative) after having used the extension on a few projects now: For full documentation of the REST Client extension, please see the project’s GitHub page here. I can’t cover all the features of this extension in a single blog post–there are just too many □. When run sequentially, the first request sets the content_hub_token variable and the second request gets the variable and uses the value in its Authorization header to authenticate against Content Hub to pull the assets. ![]() Here’s an excerpt from a sample Visual Studio Code settings.json file that defines a few variables in three different environments: For sensitive values, that should be something like Azure Key Vault, CyberArk, etc. Granted, there’s a convenience tradeoff: developers must share their variables and secrets using an external tool or service. Unlike Postman, the REST Client extension doesn’t concern itself with the handling, storing, or transmission of variables. ![]() The extension pulls environments and variables from Visual Studio Code settings (read: the settings.json file) which, upshot, is never (er…at least shouldn’t ever be) under source control developers need not worry about committing secrets to the repository. ![]() The REST Client extension handles environment variables (secret or otherwise) in a way that I consider to be elegant, which is to say it doesn’t handle them at all (and that’s a good thing!) □. The first thing you’ll want to do after installing the extension is set up your environments and variables. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |