Fields - pascalCase vs. CamelCase

[joemcbride]

Hello, I'm the original creator and maintainer of the GraphQL for .NET project. I have originally setup the project to serialize all fields as camelCase since that is my preference and seemingly idiomatic JavaScript/GraphQL. In the .NET world however there can be strong preference for PascalCase even in your returned JSON structure.

That being said, I know the spec specifically points out that a Name is case-sensitive. My question is, if I change my project to allow case-sensitive fields, which fields still need to be camelCase to conform to the spec?

These seem to be required to be camelCase

• data
• errors, with a lowercase message, locations, line and column

Ones I'm unsure about - all the fields related to introspection (and that are on introspection types), such as

• name, description, args, type, isDeprecated, deprecationReason, defaultValue, etc.
• __schema, __typename, __type, etc.

Are there others that I'm missing?

What do I need to ensure is camelCase to conform to the spec? Thanks!

[leebyron]

Where the spec points out that Names are case sensitive, what that means is that a query: { foo, Foo, FOO } is always querying three different fields, and not querying one case-insensitive field three times.

That also means that any names of types or fields referenced in the spec are required to be in the case they're described.

For example, if you implemented your introspection field to use Name instead of name that would be invalid according to the spec. And if you implemented a type sTrInG instead of String, that would also be invalid. Similarly, the response objects should use the fields data and errors, not Data and Errors so that clients can predictably use a graphql API without needing to check for case sensitivity first.

However any field or type not described directly in the GraphQL spec can be cased however you like. This is all valid:

type my_custom_type {
  MYCUSTOMFIELD: String
  my_custom_field: String
  MyCustomField: String
}

There's nothing stopping you from doing that.

However I would say that if you wanted to follow the conventions used throughout the spec, then I'd suggest using camelCase for fields and PascalCase for types.