camelCase or snake_case for json parameters

Ruby on Rails
1

Any advice on camelCase vs. snake_case for json parameters, to and from a Rails server.

I’m guessing on standardizing on snake_case, because Rails will send back database objects with with attributes in snake case.

However, it’s really hard to remember on the javascript side when an object attribute is in snake case!

Maybe a reasonable default is to give the other side what the other side expects:

  1. Rails gives JavaScript camelCase.
  2. JavaScript gives Rails snake_case.
2

Perhaps a rack middleware would be a good place to do the translation.

3

The Google JSON guide states:

Property names must conform to the following guidelines:

  • Property names should be meaningful names with defined semantics.
  • Property names must be camel-cased, ascii strings.
  • The first character must be a letter, an underscore (_) or a dollar sign ($).
  • Subsequent characters can be a letter, a digit, an underscore, or a dollar sign.
  • Reserved JavaScript keywords should be avoided (A list of reserved JavaScript keywords can be found below).
  • These guidelines mirror the guidelines for naming JavaScript identifiers. This allows JavaScript clients to access properties using dot notation. (for example, result.thisIsAnInstanceVariable). Here’s an example of an object with one property:

{
“thisPropertyIsAnIdentifier”: “identifier value”
}

4

My own convention - and this is just something I do, it’s not a standard - is to leave the attributes as snake_case, the way Rails (and the underlying database) see them.

Then in the Javascript, I continue to work with them as snake_case. I use snake_case for other variables in javascript - but lowerCamelCase for function names, UpperCamelCase for class names.

Having one convention for functions and the other for data means I always know which is which. It also is a hint as to whether I’ll need to put parentheses right after that word.

5

I’ve been doing some work with Savon for SOAP calls this week, and SAVON defaults to converting keys on both the sending and the response.

It would be nice to see this for Rails REST requests.

I will note that I didn’t realize that Savon would default to conversion, and when the relevant SOAP API didn’t correspond to the proper standards, I was in a world of pain. I was using a SOAP API based on some dot-net standards that decided to capitalize some attributes. Arghhhh…And Savon would lowercase them when sending them, as Savon assumes that any SOAP API wants camelcase for the requests.

6

Here’s an alternative take on solving the puzzle of using camelCase in JSON vs snake_case in Rails.

In Rails 4.2, create an initializer config/initializers/json_param_key_transform.rb with contents:

# Transform JSON request param keys from JSON-conventional camelCase to
# Rails-conventional snake_case:
Rails.application.config.middleware.swap(
  ::ActionDispatch::ParamsParser, ::ActionDispatch::ParamsParser,
  ::Mime::JSON => Proc.new { |raw_post|

    # Borrowed from action_dispatch/middleware/params_parser.rb except for
    # data.deep_transform_keys!(&:underscore) :
    data = ::ActiveSupport::JSON.decode(raw_post)
    data = {:_json => data} unless data.is_a?(::Hash)
    data = ::ActionDispatch::Request::Utils.deep_munge(data)
        
    # Transform camelCase param keys to snake_case:
    data.deep_transform_keys!(&:underscore)

    data.with_indifferent_access
  }
)

Restart rails server.

This swaps the default-configured ParamsParser middleware with a custom-configured ParamsParser middleware. The only difference between the two will be that this custom one changes camelCase param names to snake_case.

For example, a JSON request param named passwordConfirmation would be accessed in a controller as params[:password_confirmation]

There’s a related PR on how to make this simpler in future Rails versions, comments welcome: [RFC] JSON API mapping of camelCase *request* params to snake_case by eliotsykes · Pull Request #20389 · rails/rails · GitHub