Remove ambiguity about operationName=null in GET requests#385
Conversation
| Note: Specifying `null` for optional request parameters is equivalent to not | ||
| specifying them at all. |
There was a problem hiding this comment.
This is moved to the "JSON encoding" section. As it was, it would also apply to the "GET" section and contradict the fact that operationName=null represents an operation with the name "null" (such as query null { __typename }).
| Each of the {variables} and {extensions} parameters, if present and not the | ||
| empty string, MUST be encoded as a JSON string. |
There was a problem hiding this comment.
- used -> present for consistency
- explicit the possibility of using empty string in GET requests
| The {operationName} parameter, if supplied and not the empty string, represents | ||
| The {operationName} parameter, if present and not the empty string, represents |
There was a problem hiding this comment.
"present" for consistency
| Specifying the empty string for optional request parameters is equivalent to not | ||
| specifying them at all. | ||
|
|
||
| Note: In the final URL all of these parameters will appear in the query | ||
| component of the request URL as URL-encoded values due to the WHATWG | ||
| URLSearchParams encoding specified above. | ||
|
|
||
| Setting the value of the {operationName} parameter to the empty string is | ||
| equivalent to omitting the {operationName} parameter. | ||
|
|
There was a problem hiding this comment.
Make the rule more generic. Allow setting the empty string for variables and extensions.
operationName=null in GET requestsoperationName=null in GET requests
benjie
left a comment
There was a problem hiding this comment.
I think this is slightly normative (specifically it's explicitly allowing ?variables= and ?extensions= which were previously disallowed, I think?) but am inclined to merge it anyway since it improves consistency and clarity. Will give others a chance to review before merging.
Also unify the wording.