under_score for JSON keys? about api-standards

[delfuego]

I agree, but mostly because I don't know where "JSON uses under_score" comes from — I've never heard that as a given.

[edsu]

I think it comes largely from the Perl, Ruby and Python communities that generally prefer under_score to camelCase. Those are my people, but I recognize that there are other ways of doing it, and maybe it isn't really the place for this document to say do it one way? If there was some other JSON effort pushing for this standardization I would be happy to see it.

[konklone]

I'd prefer to be agnostic and to just recommend consistency, than to recommend camelCase. JSON emerged from JavaScript, but it's used now as a generic transport format with ubiquitous support in many languages.

Ruby and Python drive a lot of 18F's work, and to a lesser (but real) degree, Node. In Node, things do lean more camelCase, but even there it's not as absolute as in client-side JavaScript. If other 18Fers would prefer to remove the under_score recommendation, we can definitely do that.

[mlissner]

FWIW, we've thought a lot about this and came to the conclusion that underscore was the way to go even in our client-side Javascript (we use Python on the backend). It's not the recommended way of doing things, but keeping things consistent has been nice. As an extension of this, our XML and JSON also have underscores. So +1 for underscores, FWIW.

[edsu]

I agree with @mlissner and @konklone: consistency is what is important. Encouraging API designers to consciously pick under_score or camelCase and stick to it seems like the right way to go.

[jessieay]

I tend to use under_score keys because Ruby has infiltrated by brain, but there are also good arguments for using CamelCase. I am on board with recommending consistency over underscore so I opened #64