Replies: 2 comments
-
Thanks for bringing this to a discussion, @Huachao! I'm bringing my comment back here, but with the original formatting: The statement syntaxI would prefer to follow the pattern of prefixing keywords with # @import './login.http'
GET {{url}}/api/list HTTP/1.1
Authorization: Bearer {{login.response.body.$.data.id}} The keyword nameI see that we have a few options: My personal preference is for The tasks
Corner cases
Anything else? |
Beta Was this translation helpful? Give feedback.
-
I really like the idea of not having to duplicate my auth for all the files but there's one thing I'm not happy with when reading the draft. I'd expect it to actually import a callable thing. So for example:
And then import it like this:
The difference here is that it looks like |
Beta Was this translation helpful? Give feedback.
-
Copied from @rdumont #182 (comment)
The statement syntax
I would prefer to follow the pattern of prefixing keywords with @ inside a comment like it is done with @name. So what do you think about the following?
@import './login.http'
GET {{url}}/api/list HTTP/1.1
Authorization: Bearer {{login.response.body.$.data.id}}
The keyword name
I see that we have a few options: include, import, require.
My personal preference is for include, since this is basically going to be treated like a preprocessor include, as if we had copied and pasted the code into the new file. Any objections?
The tasks
Introduce include/import/require resolution to the send request command
Update http language definition to support the new include/import/require statement
Document usage in the readme
(optional) offer auto-complete for included file paths
Corner cases
Nested includes: can we agree that file paths will always be relative to each file that called the @include statement?
Anything else?
Beta Was this translation helpful? Give feedback.
All reactions