# JSON API: CamelCase or '\_'? **URL:** \ **Category:** Elasticsearch\ **Created:** [April 3, 2010, 6:25pm UTC](https://discuss.elastic.co/t/json-api-camelcase-or--/2887 "2010-04-03T18:25:38Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [April 3, 2010, 6:25pm UTC](https://discuss.elastic.co/t/json-api-camelcase-or--/2887/1 "2010-04-03T18:25:38Z")
Hi, I was just wondering (yet again) if the decision I made for the JSON based REST Api to use CamelCase make sense or not. The other option, of course is to use '\_' to separate words. What do you think? As an example, in the mappings, includeInAll will be changed to indclude\_in\_all, all response fields will be '_' based, and all HTTP parameters will be changed from CamelCase to '_' based. -shay.banon ---
**Author:** ![Sergio\_Bossa](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sergio_bossa/32/3312_2.png) [@Sergio\_Bossa](https://discuss.elastic.co/u/Sergio_Bossa)\ **Post date:** [April 3, 2010, 6:47pm UTC](https://discuss.elastic.co/t/json-api-camelcase-or--/2887/2 "2010-04-03T18:47:33Z")
+1 for camel case, mainly because of less typing. Sergio Bossa Sent by iPhone Il giorno 03/apr/2010, alle ore 20.25, Shay Banon \<[shay.banon@elasticsearch.com](mailto:shay.banon@elasticsearch.com) > ha scritto: > Hi, > > I was just wondering (yet again) if the decision I made for the > JSON based REST Api to use CamelCase make sense or not. The other > option, of course is to use '\_' to separate words. What do you think? > > As an example, in the mappings, includeInAll will be changed to > indclude\_in\_all, all response fields will be '_' based, and all HTTP > parameters will be changed from CamelCase to '_' based. > > -shay.banon ---
**Author:** ![Clinton\_Gormley](https://avatars.discourse-cdn.com/v4/letter/c/50afbb/32.png) [@Clinton\_Gormley](https://discuss.elastic.co/u/Clinton_Gormley)\ **Post date:** [April 3, 2010, 6:59pm UTC](https://discuss.elastic.co/t/json-api-camelcase-or--/2887/3 "2010-04-03T18:59:13Z")
On Sat, 2010-04-03 at 20:47 +0200, Sergio Bossa wrote: > +1 for camel case, mainly because of less typing. In Perl, we prefer underscores\_as\_separators, explained here: [perlstyle - Perl style guide - Perldoc Browser](http://perldoc.perl.org/perlstyle.html) (look for the para beginning "While short identifiers like..." However, JSON is Javascript Object Notation, and camelCase is more frequently used there, so I'd probably stick with it. clint > Sergio Bossa > Sent by iPhone > > Il giorno 03/apr/2010, alle ore 20.25, Shay Banon \<[shay.banon@elasticsearch.com](mailto:shay.banon@elasticsearch.com) > > > ha scritto: > > > Hi, > > > > I was just wondering (yet again) if the decision I made for the > > JSON based REST Api to use CamelCase make sense or not. The other > > option, of course is to use '\_' to separate words. What do you think? > > > > As an example, in the mappings, includeInAll will be changed to > > indclude\_in\_all, all response fields will be '_' based, and all HTTP > > parameters will be changed from CamelCase to '_' based. > > > > -shay.banon -- Web Announcements Limited is a company registered in England and Wales, with company number 05608868, with registered address at 10 Arvon Road, London, N5 1PR. ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [April 3, 2010, 7:27pm UTC](https://discuss.elastic.co/t/json-api-camelcase-or--/2887/4 "2010-04-03T19:27:23Z")
Some things to consider: 1. Seems like most of the REST APIs out there do use '\_', for example: twitter, digg, ... 2. couchdb, which has the same "spirit" of API as elasticsearch, uses '\_'. 3. A big question is the "eval" of those json to objects. It mainly applied to dynamic langs. Most of them use the '_' notation (perl, ruby), so it means simpler usage on their side (or maybe they automatically convert CamelCase to '_' ?). 4. As clinton mentioned, JSON is derived from javascript, and CamelCase is the norm there. Event the JSON page on wikipedia uses CamelCase. I am really on the fence on this one. Changing to '\_' means a big change, and backward comp change... . But, I prefer to nail this one now then later... -shay.banon On Sat, Apr 3, 2010 at 9:59 PM, Clinton Gormley [clinton@iannounce.co.uk](mailto:clinton@iannounce.co.uk)wrote: > On Sat, 2010-04-03 at 20:47 +0200, Sergio Bossa wrote: > > > +1 for camel case, mainly because of less typing. > > In Perl, we prefer underscores\_as\_separators, explained here: > [perlstyle - Perl style guide - Perldoc Browser](http://perldoc.perl.org/perlstyle.html) (look for the para beginning > "While short identifiers like..." > > However, JSON is Javascript Object Notation, and camelCase is more > frequently used there, so I'd probably stick with it. > > clint > > > Sergio Bossa > > Sent by iPhone > > > > Il giorno 03/apr/2010, alle ore 20.25, Shay Banon \< > > [shay.banon@elasticsearch.com](mailto:shay.banon@elasticsearch.com) > > > > > ha scritto: > > > > > Hi, > > > > > > I was just wondering (yet again) if the decision I made for the > > > JSON based REST Api to use CamelCase make sense or not. The other > > > option, of course is to use '\_' to separate words. What do you think? > > > > > > As an example, in the mappings, includeInAll will be changed to > > > indclude\_in\_all, all response fields will be '_' based, and all HTTP > > > parameters will be changed from CamelCase to '_' based. > > > > > > -shay.banon > > -- > Web Announcements Limited is a company registered in England and Wales, > with company number 05608868, with registered address at 10 Arvon Road, > London, N5 1PR. ---
**Author:** ![mooky](https://avatars.discourse-cdn.com/v4/letter/m/43a26b/32.png) [@mooky](https://discuss.elastic.co/u/mooky)\ **Post date:** [April 3, 2010, 7:28pm UTC](https://discuss.elastic.co/t/json-api-camelcase-or--/2887/5 "2010-04-03T19:28:44Z")
CamelCase is easier on the eye & less chars. What makes you wonder about it? -Nick On 3 Apr 2010, at 19:25, Shay Banon [shay.banon@elasticsearch.com](mailto:shay.banon@elasticsearch.com) wrote: > Hi, > > I was just wondering (yet again) if the decision I made for the > JSON based REST Api to use CamelCase make sense or not. The other > option, of course is to use '\_' to separate words. What do you think? > > As an example, in the mappings, includeInAll will be changed to > indclude\_in\_all, all response fields will be '_' based, and all HTTP > parameters will be changed from CamelCase to '_' based. > > -shay.banon ---
**Author:** ![mooky](https://avatars.discourse-cdn.com/v4/letter/m/43a26b/32.png) [@mooky](https://discuss.elastic.co/u/mooky)\ **Post date:** [April 3, 2010, 7:33pm UTC](https://discuss.elastic.co/t/json-api-camelcase-or--/2887/6 "2010-04-03T19:33:14Z")
Our mails crossed in the air 馃槈 On 3 April 2010 20:29, Nick Minutello [nick.minutello@gmail.com](mailto:nick.minutello@gmail.com) wrote: > CamelCase is easier on the eye & less chars. > > What makes you wonder about it? > > -Nick > > On 3 Apr 2010, at 19:25, Shay Banon [shay.banon@elasticsearch.com](mailto:shay.banon@elasticsearch.com) wrote: > > Hi, > > > I was just wondering (yet again) if the decision I made for the JSON > > based REST Api to use CamelCase make sense or not. The other option, of > > course is to use '\_' to separate words. What do you think? > > > > As an example, in the mappings, includeInAll will be changed to > > indclude\_in\_all, all response fields will be '_' based, and all HTTP > > parameters will be changed from CamelCase to '_' based. > > > > -shay.banon ---
**Author:** ![Berkay\_Mollamustafao](https://avatars.discourse-cdn.com/v4/letter/b/22d042/32.png) [@Berkay\_Mollamustafao](https://discuss.elastic.co/u/Berkay_Mollamustafao)\ **Post date:** [April 3, 2010, 7:33pm UTC](https://discuss.elastic.co/t/json-api-camelcase-or--/2887/7 "2010-04-03T19:33:44Z")
+1 Regards, Berkay Mollamustafaoglu mberkay on yahoo, google and skype On Sat, Apr 3, 2010 at 3:29 PM, Nick Minutello [nick.minutello@gmail.com](mailto:nick.minutello@gmail.com)wrote: > CamelCase is easier on the eye & less chars. > > What makes you wonder about it? > > -Nick > > On 3 Apr 2010, at 19:25, Shay Banon [shay.banon@elasticsearch.com](mailto:shay.banon@elasticsearch.com) wrote: > > Hi, > > > I was just wondering (yet again) if the decision I made for the JSON > > based REST Api to use CamelCase make sense or not. The other option, of > > course is to use '\_' to separate words. What do you think? > > > > As an example, in the mappings, includeInAll will be changed to > > indclude\_in\_all, all response fields will be '_' based, and all HTTP > > parameters will be changed from CamelCase to '_' based. > > > > -shay.banon ---
**Author:** ![Clinton\_Gormley](https://avatars.discourse-cdn.com/v4/letter/c/50afbb/32.png) [@Clinton\_Gormley](https://discuss.elastic.co/u/Clinton_Gormley)\ **Post date:** [April 3, 2010, 7:53pm UTC](https://discuss.elastic.co/t/json-api-camelcase-or--/2887/8 "2010-04-03T19:53:03Z")
On Sat, 2010-04-03 at 20:29 +0100, Nick Minutello wrote: > CamelCase is easier on the eye & less chars. I think that's a matter of what you're used to - for me, I find underscores make it much easier to read. I find camelCase annoying. > 茂禄驴 > > 1. Seems like most of the REST APIs out there do use '\_', for example: > twitter, digg, ... > 2. couchdb, which has the same "spirit" of API as elasticsearch, uses > '\_'. Wasn't aware of the above 2 points > 1. A big question is the "eval" of those json to objects. It mainly > applied to dynamic langs. Most of them use the '\_' notation (perl, > ruby), Not sure if the majority use underscores. Perl and Ruby OK. JS, no. php anything goes, and Python looks like a mixture, depending on what the 'thing' is, eg [http://github.com/defnull/bottle/blob/master/startbottle.py](http://github.com/defnull/bottle/blob/master/startbottle.py) > so it means simpler usage on their side (or maybe they automatically > convert CamelCase to '\_' ?). They definitely don't convert automatically, although a simple regex would suffice, eg in Perl: ``` $var = 'foo_bar_baz'; $var =~ s/_(\w)/\u$1/g; -> 'fooBarBaz' $var=~s/([[0-9_[:lower:]])([[:upper:]])/$1_\l$2/g -> 'foo_bar_baz' If only dealing with ascii, then: $var=~s/([0-9_a-z])([A-Z])/$1_\l$2/g ``` > 1. As clinton mentioned, JSON is derived from javascript, and > CamelCase is the norm there. Event the JSON page on wikipedia uses > CamelCase. yes - probably because of the java inspiration of JS. Certainly, in my API, I'm using underscores in my methods, eg clear\_cache, delete\_by\_query, and something similar for the parameters (although I'm trying to support both). -- Web Announcements Limited is a company registered in England and Wales, with company number 05608868, with registered address at 10 Arvon Road, London, N5 1PR. ---
**Author:** ![Sergio\_Bossa](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sergio_bossa/32/3312_2.png) [@Sergio\_Bossa](https://discuss.elastic.co/u/Sergio_Bossa)\ **Post date:** [April 3, 2010, 8:16pm UTC](https://discuss.elastic.co/t/json-api-camelcase-or--/2887/9 "2010-04-03T20:16:25Z")
On Sat, Apr 3, 2010 at 9:27 PM, Shay Banon [shay.banon@elasticsearch.com](mailto:shay.banon@elasticsearch.com) wrote: > I am really on the fence on this one. Changing to '\_' means a big change, > and backward comp change... . But, I prefer to nail this one now then > later... I second Clinton's statement: talking about readability and typing, it may depend on people habits. Anyways, I don't see a real reason to change that and break backward compatibility. But I've already casted my vote, so I'll not speak anymore on the subject 馃槈 Cheers! -- Sergio Bossa [http://www.linkedin.com/in/sergiob](http://www.linkedin.com/in/sergiob) ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [April 3, 2010, 11:27pm UTC](https://discuss.elastic.co/t/json-api-camelcase-or--/2887/10 "2010-04-03T23:27:28Z")
Hi, Well, it seems like the more I look around, the more I see the '_' being used and not CamelCase... . All nosql ones (at least the ones I know) that speak JSON do '_' (riak, couchdb, mongodb). All the APIs that I look at (twitter, digg, ...). Currently, my decision is to change everything to work with '\_'. This means all the JSON based interface, the HTTP parameters, and all the settings. This is not something that I really want to do, as its going to take more of tomorrow to do :), but I think that its important to create a common JSON practice among different REST API exposing systems. Last chance till tomorrow to voice firm objection against it. As a side note, I really don't mind that much either way. I prefer the '_' notation (probably due to my realtime C background, even though I do tons of Java), but chose the CamelCase because of JSON heritage. But, based on all that I have seen "out there", it seems like '_' is the way to go. -shay.banon On Sat, Apr 3, 2010 at 11:16 PM, Sergio Bossa [sergio.bossa@gmail.com](mailto:sergio.bossa@gmail.com)wrote: > On Sat, Apr 3, 2010 at 9:27 PM, Shay Banon [shay.banon@elasticsearch.com](mailto:shay.banon@elasticsearch.com) > wrote: > > > I am really on the fence on this one. Changing to '\_' means a big change, > > and backward comp change... . But, I prefer to nail this one now then > > later... > > I second Clinton's statement: talking about readability and typing, it > may depend on people habits. > Anyways, I don't see a real reason to change that and break backward > compatibility. > > But I've already casted my vote, so I'll not speak anymore on the subject > 馃槈 > > Cheers! > > -- > Sergio Bossa > [http://www.linkedin.com/in/sergiob](http://www.linkedin.com/in/sergiob) ---
**Author:** ![mooky](https://avatars.discourse-cdn.com/v4/letter/m/43a26b/32.png) [@mooky](https://discuss.elastic.co/u/mooky)\ **Post date:** [April 3, 2010, 11:45pm UTC](https://discuss.elastic.co/t/json-api-camelcase-or--/2887/11 "2010-04-03T23:45:18Z")
Youre such a conformist.... 馃槢 On 4 April 2010 00:27, Shay Banon [shay.banon@elasticsearch.com](mailto:shay.banon@elasticsearch.com) wrote: > Hi, > > Well, it seems like the more I look around, the more I see the '_' being > used and not CamelCase... . All nosql ones (at least the ones I know) that > speak JSON do '_' (riak, couchdb, mongodb). All the APIs that I look at > (twitter, digg, ...). > > Currently, my decision is to change everything to work with '\_'. This > means all the JSON based interface, the HTTP parameters, and all the > settings. This is not something that I really want to do, as its going to > take more of tomorrow to do :), but I think that its important to create a > common JSON practice among different REST API exposing systems. > > Last chance till tomorrow to voice firm objection against it. As a side > note, I really don't mind that much either way. I prefer the '_' notation > (probably due to my realtime C background, even though I do tons of Java), > but chose the CamelCase because of JSON heritage. But, based on all that I > have seen "out there", it seems like '_' is the way to go. > > -shay.banon > > On Sat, Apr 3, 2010 at 11:16 PM, Sergio Bossa [sergio.bossa@gmail.com](mailto:sergio.bossa@gmail.com)wrote: > > > On Sat, Apr 3, 2010 at 9:27 PM, Shay Banon [shay.banon@elasticsearch.com](mailto:shay.banon@elasticsearch.com) > > wrote: > > > > > I am really on the fence on this one. Changing to '\_' means a big > > > change, > > > and backward comp change... . But, I prefer to nail this one now then > > > later... > > > > I second Clinton's statement: talking about readability and typing, it > > may depend on people habits. > > Anyways, I don't see a real reason to change that and break backward > > compatibility. > > > > But I've already casted my vote, so I'll not speak anymore on the subject > > 馃槈 > > > > Cheers! > > > > -- > > Sergio Bossa > > [http://www.linkedin.com/in/sergiob](http://www.linkedin.com/in/sergiob) ---
**Author:** ![dominict](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dominict/32/3351_2.png) [@dominict](https://discuss.elastic.co/u/dominict)\ **Post date:** [April 3, 2010, 11:45pm UTC](https://discuss.elastic.co/t/json-api-camelcase-or--/2887/12 "2010-04-03T23:45:58Z")
I'm used to camel case, but that's just from the Java background. I'd never noticed the twitter api used '\_' between the words rather than camel; if it provide consistency with other api's, and nosql products. Then it does seem that's a good swaying point. I don't have a strong opinion either way though. I've only just started having a look into elastic. /dom ---
**Author:** ![Lukas\_Vlcek1](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/lukas_vlcek1/32/819_2.png) [@Lukas\_Vlcek1](https://discuss.elastic.co/u/Lukas_Vlcek1)\ **Post date:** [April 4, 2010, 6:16am UTC](https://discuss.elastic.co/t/json-api-camelcase-or--/2887/13 "2010-04-04T06:16:46Z")
Can't it simply support both? Lukas On Sat, Apr 3, 2010 at 8:25 PM, Shay Banon [shay.banon@elasticsearch.com](mailto:shay.banon@elasticsearch.com)wrote: > Hi, > > I was just wondering (yet again) if the decision I made for the JSON > based REST Api to use CamelCase make sense or not. The other option, of > course is to use '\_' to separate words. What do you think? > > As an example, in the mappings, includeInAll will be changed to > indclude\_in\_all, all response fields will be '_' based, and all HTTP > parameters will be changed from CamelCase to '_' based. > > -shay.banon ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [April 4, 2010, 8:49am UTC](https://discuss.elastic.co/t/json-api-camelcase-or--/2887/14 "2010-04-04T08:49:26Z")
It can when parsing (but makes thing more complicated), but when generating JSON, a decision need to be made. I guess there could be a flag set for it, we'll see. I am going to start working on moving to '\_'. -shay.banon On Sun, Apr 4, 2010 at 9:16 AM, Luk谩拧 Vl膷ek [lukas.vlcek@gmail.com](mailto:lukas.vlcek@gmail.com) wrote: > Can't it simply support both? > > Lukas > > On Sat, Apr 3, 2010 at 8:25 PM, Shay Banon [shay.banon@elasticsearch.com](mailto:shay.banon@elasticsearch.com)wrote: > > > Hi, > > > > I was just wondering (yet again) if the decision I made for the JSON > > based REST Api to use CamelCase make sense or not. The other option, of > > course is to use '\_' to separate words. What do you think? > > > > As an example, in the mappings, includeInAll will be changed to > > indclude\_in\_all, all response fields will be '_' based, and all HTTP > > parameters will be changed from CamelCase to '_' based. > > > > -shay.banon ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [April 4, 2010, 2:20pm UTC](https://discuss.elastic.co/t/json-api-camelcase-or--/2887/15 "2010-04-04T14:20:43Z")
ok, committed, see: [Move from CamelCase to '\_' casing 路 Issue #116 路 elastic/elasticsearch 路 GitHub](http://github.com/elasticsearch/elasticsearch/issues/issue/116). Sorry for the backward comp change... -shay.banon On Sun, Apr 4, 2010 at 11:49 AM, Shay Banon [shay.banon@elasticsearch.com](mailto:shay.banon@elasticsearch.com)wrote: > It can when parsing (but makes thing more complicated), but when generating > JSON, a decision need to be made. I guess there could be a flag set for it, > we'll see. I am going to start working on moving to '\_'. > > -shay.banon > > On Sun, Apr 4, 2010 at 9:16 AM, Luk谩拧 Vl膷ek [lukas.vlcek@gmail.com](mailto:lukas.vlcek@gmail.com) wrote: > > > Can't it simply support both? > > > > Lukas > > > > On Sat, Apr 3, 2010 at 8:25 PM, Shay Banon [shay.banon@elasticsearch.com](mailto:shay.banon@elasticsearch.com)wrote: > > > > > Hi, > > > > > > I was just wondering (yet again) if the decision I made for the JSON > > > based REST Api to use CamelCase make sense or not. The other option, of > > > course is to use '\_' to separate words. What do you think? > > > > > > As an example, in the mappings, includeInAll will be changed to > > > indclude\_in\_all, all response fields will be '_' based, and all HTTP > > > parameters will be changed from CamelCase to '_' based. > > > > > > -shay.banon ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [April 4, 2010, 3:28pm UTC](https://discuss.elastic.co/t/json-api-camelcase-or--/2887/16 "2010-04-04T15:28:31Z")
Pushed updated docs to reflect it (they correspond now to 0.6, so be careful). Also uploaded new snapshots to maven. I was planning to release 0.6 today/tomorrow, but I am going to wait a few days so people can flush out bugs if there are.... -shay.banon On Sun, Apr 4, 2010 at 5:20 PM, Shay Banon [shay.banon@elasticsearch.com](mailto:shay.banon@elasticsearch.com)wrote: > ok, committed, see: > [Move from CamelCase to '\_' casing 路 Issue #116 路 elastic/elasticsearch 路 GitHub](http://github.com/elasticsearch/elasticsearch/issues/issue/116). Sorry for > the backward comp change... > > -shay.banon > > On Sun, Apr 4, 2010 at 11:49 AM, Shay Banon [shay.banon@elasticsearch.com](mailto:shay.banon@elasticsearch.com)wrote: > > > It can when parsing (but makes thing more complicated), but when > > generating JSON, a decision need to be made. I guess there could be a flag > > set for it, we'll see. I am going to start working on moving to '\_'. > > > > -shay.banon > > > > On Sun, Apr 4, 2010 at 9:16 AM, Luk谩拧 Vl膷ek [lukas.vlcek@gmail.com](mailto:lukas.vlcek@gmail.com)wrote: > > > > > Can't it simply support both? > > > > > > Lukas > > > > > > On Sat, Apr 3, 2010 at 8:25 PM, Shay Banon \<[shay.banon@elasticsearch.com](mailto:shay.banon@elasticsearch.com) > > > > > > > wrote: > > > > > > > Hi, > > > > > > > > I was just wondering (yet again) if the decision I made for the JSON > > > > based REST Api to use CamelCase make sense or not. The other option, of > > > > course is to use '\_' to separate words. What do you think? > > > > > > > > As an example, in the mappings, includeInAll will be changed to > > > > indclude\_in\_all, all response fields will be '_' based, and all HTTP > > > > parameters will be changed from CamelCase to '_' based. > > > > > > > > -shay.banon ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 4:24am UTC](https://discuss.elastic.co/t/json-api-camelcase-or--/2887/17 "2017-07-06T04:24:52Z")