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
+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
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
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 (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 iPhoneIl giorno 03/apr/2010, alle ore 20.25, Shay Banon <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.
Some things to consider:
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.ukwrote:
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 (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 iPhoneIl giorno 03/apr/2010, alle ore 20.25, Shay Banon <
shay.banon@elasticsearch.comha 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.
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
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
Our mails crossed in the air 
On 3 April 2010 20:29, Nick Minutello 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 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
+1
Regards,
Berkay Mollamustafaoglu
mberkay on yahoo, google and skype
On Sat, Apr 3, 2010 at 3:29 PM, Nick Minutello nick.minutello@gmail.comwrote:
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 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
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.

- Seems like most of the REST APIs out there do use '_', for example:
twitter, digg, ...- couchdb, which has the same "spirit" of API as elasticsearch, uses
'_'.
Wasn't aware of the above 2 points
- 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
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
- 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.
On Sat, Apr 3, 2010 at 9:27 PM, Shay Banon 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
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.comwrote:
On Sat, Apr 3, 2010 at 9:27 PM, Shay Banon 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
Youre such a conformist.... 
On 4 April 2010 00:27, Shay Banon 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.comwrote:
On Sat, Apr 3, 2010 at 9:27 PM, Shay Banon 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
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
Can't it simply support both?
Lukas
On Sat, Apr 3, 2010 at 8:25 PM, Shay Banon shay.banon@elasticsearch.comwrote:
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
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 wrote:
Can't it simply support both?
Lukas
On Sat, Apr 3, 2010 at 8:25 PM, Shay Banon shay.banon@elasticsearch.comwrote:
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
ok, committed, see:
Move from CamelCase to '_' casing · Issue #116 · elastic/elasticsearch · GitHub. Sorry for
the backward comp change...
-shay.banon
On Sun, Apr 4, 2010 at 11:49 AM, Shay Banon shay.banon@elasticsearch.comwrote:
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 wrote:
Can't it simply support both?
Lukas
On Sat, Apr 3, 2010 at 8:25 PM, Shay Banon shay.banon@elasticsearch.comwrote:
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
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.comwrote:
ok, committed, see:
Move from CamelCase to '_' casing · Issue #116 · elastic/elasticsearch · GitHub. Sorry for
the backward comp change...-shay.banon
On Sun, Apr 4, 2010 at 11:49 AM, Shay Banon shay.banon@elasticsearch.comwrote:
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.comwrote:
Can't it simply support both?
Lukas
On Sat, Apr 3, 2010 at 8:25 PM, Shay Banon <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
© 2020. All Rights Reserved - Elasticsearch
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant logo are trademarks of the Apache Software Foundation in the United States and/or other countries.