pluggable approach for request transformation
cedric05 opened this issue · comments
There are scenarios where running custom transformations before making a http request, ideally test_script is a way to write those out.
Not all transformations can be written in test_script, there should be a way for dothttp to figure out plugin and load those plugin and apply those tranformations easily.
This way users can write their own custom plugins, install and use.
Http item can have a syntax like
@plugin("<pluginid>", ["list of arguements"])
GET "https://httpbin.org/get"
using pluginid, dothttp will load that plugin and apply that transformation.
For example:
GET "https://httpbin.org/get"
hawkauth plugin will apply headers.
For Plugin after researching here is the plan, i think would make sense
- leverage similar concept of aws where in, each plugin is python zip (includes all dependencies packaged).
- dothttp, can provide a built-in way to install or provide a new installer packages from remote.
- installer will store package in centralized locations.
- installer will update metadata in specific file '~/.dothttp/installed_packages'
- dothttp or dotextensions will load all installed packages beforehand.
- plugin is used for request, it will try to load and apply that request transformer.
aws concepts
AWS lambda uses packaged .zip
files to load lamdba function defined.
aws sam uses package
to package lamdba python function to ease deployment.
ref: https://github.com/aws/aws-sam-cli/blob/develop/samcli/commands/package/command.py
module built via pyinstaller (like dothttp) can load packages from by appending path to packages to sys.path
. after that, module can be loaded via importlib.import_module('package')
.