Json-api: Requirement to use camelCase

[Niklas9]

I would like to consider forcing the use of camelCase naming in this standard.
As it's JSON as in JavaScript Object Notation and it might be one of the only thing that's consistent in JavaScript - example - it is Array.prototype.forEach and not Array.prototype.for_each.

(I doubt this hasn't been discussed here before, but I couldn't find anything about it.)

[kevin-brown]

I don't think this should be enforced by the specification.

This isn't something that should vary greatly between languages, and I can't understand why it would necessarily make a difference if snake_case or camelCase (or another variation) is being used. APIs aren't only consumed by JavaScript clients, and I can see valid arguments for enforcing other casing styles (ember-json-api uses dashes, drf-json-api uses underscores, the rails implementation might also), and those are just a few examples of the implementations that currently exist for JSON API.

[wvteijlingen]

The fact that there are now already three different implementations indicates to me the need to specify a preferred style. I think we could use a SHOULD for this, so we can at least add a recommendation, but still allow API authors to deviate.

I personally use underscores, but either style is fine by me.

[vslinko]

:+1: for SHOULD

[wvteijlingen]

Any other opinions on a preferred style? If not I would like to add this to the spec as:

Each attribute SHOULD be formatted using underscore_case.

[vslinko]

:+1: for camelCase

[vslinko]

Because most API clients is JavaScript applications which is camelCased.

[gr0uch]

I don't think the spec should be at all concerned with naming, and the co-author also disagrees with enforcing naming standards in issue #127.

[wvteijlingen]

I agree that the spec shouldn't strictly define the naming scheme. But why shouldn't the spec make at least a recommendation using 'should'? It provides a base on which authors of generic client libraries can build. It still allows you to deviate if you want to.

[timbunce]

If the spec makes a recommendation using 'should' then some 'authors of generic client libraries' are more likely to only support the recommended style, perhaps out of personal preference and/or natural laziness, and the 'should' in the spec will be used to defend that position. Then people wanting to provide an API to a large system that uses the other style are less likely to choose JSON-API.

In my view:

• The way multi-word key names are composed should be outside the scope of the JSON-API spec. It's just a name.
• Adoption of JSON-API will almost inevitably be hindered by recommending one style over another.
• There are more important issues to discuss and resolve.

[dgeb]

We've gone with a "recommendation" for dasherized. This is not a part of the base spec and of course won't be enforced. In #341, we originally made this a requirement of the spec, but there was a lot of pushback and it was moved. Ultimately, names and URLs are opaque to the spec.

[garrettmac]

Thought I was worth sharing Google JSON Style Guide, where:

• Property names must be camel-cased, ascii strings.

This should be reason enough to adapt camelCase so I created a PR https://github.com/json-api/json-api/pull/1247