-
Notifications
You must be signed in to change notification settings - Fork 701
Description
Problem to solve
What I'd like to see is the ability to share data across Hurl files. In my particular case, sharing JWT tokens would be the main use, but I'm sure plenty of other benefits would come from this.
I believe this is achievable with the current version of Hurl by running it in two or more steps and creating temporary output files. However, targeting files to be run in a specific order and cleaning up temp files can be cumbersome. If there's a more sane approach to this, please let me know, and I'll close the issue.
Proposal
I've thought of two possible ways this could be achieved:
-
Run Hurl files as functions and capture their captured data.
Example:# auth.hurl POST https://www.example.com/auth/sign-in { "email": "john@example.com", "password": "example" } HTTP 200 [Captures] token: jsonpath "$.session.token"# order.hurl auth: {{./auth.hurl}} GET https://www.example.com/orders/list Authorization: Bearer {{auth.token}} HTTP 200 # or GET https://www.example.com/orders/list Authorization: Bearer capture ./auth.hurl $.token HTTP 200 -
Set captures as
global, which will be shared across files that run as part of the samehurlcommand.
To make this work, a mechanism would still be needed to order the running of files.
Example:# auth.hurl POST https://www.example.com/auth/sign-in { "email": "john@example.com", "password": "example" } HTTP 200 [CapturesGlobal] token: jsonpath "$.session.token"# order.hurl GET https://www.example.com/orders/list Authorization: Bearer {{global.token}} HTTP 200
The second approach could introduce overwrites to captured data, which would be hard to debug, and in itself is incomplete because of the lack of file ordering.
Additional context and resources
The feature would make it easier to implement reusable parts. Use cases could include:
- Authentication
- Common HTTP headers
- Complex JSON or form data