Switch to the JSON Pointer standard for map field operations paths #56
Description
The IETF RFC 6901 “JSON Pointer” spec defines a string syntax for identifying a specific value within a JSON document.
Ideally, the GraphQL multipart request spec would use JSON pointer strings instead of less standard object-path strings for operations paths in the map field array.
Here is an example of the difference for the map field JSON for the batching example:
{
"0": [
- "0.variables.file"
+ "/0/variables/file"
],
"1": [
- "1.variables.files.0"
+ "/1/variables/files/0"
],
"2": [
- "1.variables.files.1"
+ "/1/variables/files/1"
]
}Benefits of switching to the JSON Pointer format:
- It has a detailed specification.
- It’s a proposed web standard.
- It should be more familiar to programers across languages.
- There should be more tools and libraries available across languages to work with it, making implementations easier.
Cons:
- It’s 1 character longer per path, leading to slightly larger request content lengths.
- The
/separators are “uglier” to people who would intuitively use.as that's what's used to reference properties within objects in languages such as JS. - A spec change like this would be a massive breaking change and would require simultaneous client and server implementation updates.
The benefits don't enable new features or capability and are probably not worth the pain. Until now there have been few, if any, complaints about the format for operations paths. It might make sense to leave this spec as it is until it moves to an official GraphQL Foundation GraphQL over HTTP spec (see graphql/graphql-over-http#7).