-
Notifications
You must be signed in to change notification settings - Fork 7
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
add directives ie @noredirect
#9
Comments
Along these same lines, I've been thinking about a feature like https://learning.postman.com/docs/postman/sending-api-requests/requests/#binary-data or for sending a GraphQL request (currently formatting the GraphQL request is a little messy). I wanted to suggest some of the ideas for syntax I've been playing around with:
or
The problem with this is it gets harder to define where the body starts and it also might not sync up as smoothly with OR What if we leveraged custom headers for dot-http:
|
For context, the I think if dot-http was to support binary files I would imagine it to have a similar syntax:
Not really liking the custom headers, the intent of this project is to try to minimize the difference between what the developer imagines is being sent on the wire compared to what is expressed in the script.
Can you give some examples of this? I haven't been making GraphQL requests with dot-http so some more context would be helpful. |
Thanks for the context, it helps / I didn't know about IntelliJ's version. GraphQL requests are usually encapsulated in json, so a request body like:
would be
which is hard to edit/read after removing the newlines. The real problem is that json doesn't support multiline strings. The API tests clients that I'm familiar with abstract out the json part and let you just write GraphQL queries. How I've been handling it is:
which I guess could be helped with a pre-request script |
First off, just wanted to say: very cool! My original use-case for dot-http was limited so I just kept the bare features that I needed. Your use-case let's us grow it be useful to a wider audience. The directives should focus on changing the request in ways that are unrelated to it's contents. This is illustrated in that help doc I linked:
That was my intention for directives in general and would be following that for the future.
I think you are on to something here and I could see this being done in a way that is consistent with other parts of dot-http:
Note the symmetry of the syntax:
Since I don't see solving this problem with a directive, let's move over to this issue: #42 |
No description provided.
The text was updated successfully, but these errors were encountered: