Discuss casing in the API

[spalger]

Expanded version of #5412

We are looking to expose some new API's in #3709 and I think we should discuss how we should be casing the urls, query string parameters, and bodies.

Options:

#	path	query string	body
1	one-word/camelCase	camelCase	camelCase
2	one-word/snake_case	snake_case	snake_case
3	snake_case	snake_case	camelCase
4	kebab-case	kebab-case	camelCase
5	kebab-case	snake_case	camelCase

In the wild:

name	style
elasticsearch	2
Github	3
Facebook	mostly one-word, kebab-case for one, snake_case for others
Google	mix of all
...	feel free to add more

What do you think?

[spalger]

@Bargs @rashidkpc I have expanded the discussion a bit and would appreciate if you would leave some feedback

[rashidkpc]

Elasticsearch, really the only other API we really need to stay consistent with whenever possible, uses snake_case in the path, body and query string.

[spalger]

I am a fan of 1, because it is consistent with the rest of our code and translates effortlessly to how we will be utilizing the values.

I appreciate @rashidkpc's point though, so I'll give half of my vote to that so long as we can commit to converting these values into camelCase before using them. I worry that this will end up with us putting a bunch of resp.body.snake_cased_property references in the code.

[Bargs]

snake_case everywhere is fine with me. I also agree with @spalger that we should camelize the names in our own client code. The serialization format of the API shouldn't dictate how we design our domain objects. Getting into the habit of normalizing the data will save us from a lot of headaches if we consume other APIs in the future.

[spalger]

We basically agree here, snake_case everywhere and camelCase in the code. When you use a value from the api response transform it into camelCase.