Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Recommending camelCase for JSON members #1255
In addition I also wanted to share the following:
Several well-established style guides recommend camelCase:
Google JSON Style Guide (they follow the JSON.org spec):
W3resource(same thing) state:
I would enjoy feedback from the maintainers of the project and the community.
@garrettmac Thank you for opening this as an issue for discussion separate from your original PR.
However, this decision does have a bit of a ripple effect.
I have not heard a strong argument to change the recommendations for URL segments from kebab-case. And the current recommendation for resource collection URLs is:
We could change the recommendation for resource types to follow the general JSON member recommendation, which would involve changing this URL recommendation to involve a transformation. However, it's also possible to just leave this alone by keeping the recommendation for resource types as kebab-case.
And if we accept a transformation, then it's also possible to consider changing the recommendation for resource types to be singular instead of plural (which is not a purely mechanical transformation).
Anyway, I'm just pulling on these threads a bit because everything's connected and we want to have a coherent set of recommendations.
I oppose changing the recommendation to camelCase. Kebab-case is easier to serialize/deserialize than camelCase for languages and frameworks that do not use camelCase idiomatically.
If JSON API is meant to be a wire protocol, the data structures should be optimized for the transport of data. Using the response JSON as a direct interface to the data does not seem to be the intent of the specification. A JSON API response for a compound document, for example, is not a particularly convenient data structure to use directly. It's meant to be mapped to an application's data model before the application uses it.
In non JSONAPI services I always used snake case over camel case.
However I have no objection against recommending for camel case.
Camel case in url’s I would not favor, in that case I prefer kebab case.
I think for JSONAPI recommending the kind of naming conventions is a good thing.
Thank you for starting this thread. Naming questions are always hard ones, and it would be better to have recommendations for all the parts of the specification.
We've discussed keys name convention in our company so far and one of the benefits of the
Same for the document body.
But at the end, frontend team doesn't care about json properties naming because normalizer converts them to
If choosing between
I can see two benefit from
If we'll have
But if we'll have
Keep in mind that backend libraries could returns data in the same format you've requested it in URI. So if you'll write
I'd vote for consistency. If make document properties
I understood one more thing. If we'll make relationships camelized then relationship links will be camelized too:
@dgeb is there any recommendations from W3C or something similar what declare that URI should be lower-cased?
Personally I've used hyphens all the time in URIs, it works great for SEO. But now I understand that front-end application could have human-readable endpoints with
I've found only W3C: HTML and URLs:
Here is WHATWG URL Specification, but there is nothing about camel or kebab case there.
There are a lot of discussions on stack overflow related to this question, here is one of them: https://stackoverflow.com/questions/10302179/hyphen-underscore-or-camelcase-as-word-delimiter-in-uris