Skip to content
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

Open
bayne opened this issue Jan 13, 2020 · 4 comments
Open

add directives ie @noredirect #9

bayne opened this issue Jan 13, 2020 · 4 comments

Comments

@bayne
Copy link
Owner

bayne commented Jan 13, 2020

No description provided.

@dylanowen
Copy link
Contributor

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:
Something between the headers and the body

...
authorization: {{access_token}}

{% body: file(image.png) %}
...

or

...
authorization: {{access_token}}

{% body: graphql %}
query {
   request {
       name
   }
}
...

The problem with this is it gets harder to define where the body starts and it also might not sync up as smoothly with @noredirect?

OR

What if we leveraged custom headers for dot-http:

...
authorization: {{access_token}}
dot-noredirect: true
dot-body: file(image.png)
...

@bayne
Copy link
Owner Author

bayne commented Feb 14, 2020

For context, the @noredirect was essentially to match what's available on IntelliJ's HTTP editor: https://www.jetbrains.com/help/idea/exploring-http-syntax.html#enable-disable-redirects

I think if dot-http was to support binary files I would imagine it to have a similar syntax:

< ./input_file.bin

... What if we leveraged custom headers for dot-http: ...

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.

... for sending a GraphQL request (currently formatting the GraphQL request is a little messy).

Can you give some examples of this? I haven't been making GraphQL requests with dot-http so some more context would be helpful.

@dylanowen
Copy link
Contributor

dylanowen commented Feb 14, 2020

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:

{
  leftComparison: hero(episode: EMPIRE) {
    ...comparisonFields
  }
  rightComparison: hero(episode: JEDI) {
    ...comparisonFields
  }
}

fragment comparisonFields on Character {
  name
  appearsIn
  friends {
    name
  }
}

would be

POST {{base_url}}/graphql/

{
   "query": "{   leftComparison: hero(episode: EMPIRE) {     ...comparisonFields   }   rightComparison: hero(episode: JEDI) {     ...comparisonFields   } }  fragment comparisonFields on Character {   name   appearsIn   friends {     name   } }"
   "variables": {}
}

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:

GET {{base_url}}/ping

> {%
   client.global.set('QUERY', '{\
    leftComparison: hero(episode: EMPIRE) {\
      ...comparisonFields\
    }\
    rightComparison: hero(episode: JEDI) {\
      ...comparisonFields\
    }\
  }\
  fragment comparisonFields on Character {\
    name\
    appearsIn\
    friends {\
      name\
    }\
  }');
%}

###

POST {{base_url}}/graphql

{
   "query": "{{QUERY}}"
}

which I guess could be helped with a pre-request script

@bayne
Copy link
Owner Author

bayne commented Feb 15, 2020

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:

  • @no-redirect says to not follow redirects and just provide the actual response. No changes to the body or the headers, just behavior.
  • @no-log changes how the output is displayed to the user, once again does not modify the request

That was my intention for directives in general and would be following that for the future.

which I guess could be helped with a pre-request script

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:

POST {{base_url}}/graphql

< {%
  var query = '{\
    leftComparison: hero(episode: EMPIRE) {\
      ...comparisonFields\
    }\
    rightComparison: hero(episode: JEDI) {\
      ...comparisonFields\
    }\
    }\
    fragment comparisonFields on Character {\
      name\
      appearsIn\
      friends {\
        name\
      }\
  }';

  return {
    "query": query
  };
%}

> {% console.log(response); %}

Note the symmetry of the syntax:

  • < {% ... %} for a request body generator
  • > {% ... %} for a response handler (existing)

Since I don't see solving this problem with a directive, let's move over to this issue: #42

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants