JSON API: CamelCase or '_'?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

JSON API: CamelCase or '_'?

kimchy
Administrator
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

Reply | Threaded
Open this post in threaded view
|

Re: JSON API: CamelCase or '_'?

Sergio Bossa
+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 <[hidden email]
 > 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
>
Reply | Threaded
Open this post in threaded view
|

Re: JSON API: CamelCase or '_'?

Clinton Gormley
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:
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 <[hidden email]
>  > 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.

Reply | Threaded
Open this post in threaded view
|

Re: JSON API: CamelCase or '_'?

kimchy
Administrator
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 <[hidden email]> 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:
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 <[hidden email]
>  > 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.


Reply | Threaded
Open this post in threaded view
|

Re: JSON API: CamelCase or '_'?

mooky
In reply to this post by kimchy
CamelCase is easier on the eye & less chars.

What makes you wonder about it?

-Nick

On 3 Apr 2010, at 19:25, Shay Banon <[hidden email]>  
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
>
Reply | Threaded
Open this post in threaded view
|

Re: JSON API: CamelCase or '_'?

mooky
Our mails crossed in the air ;)

On 3 April 2010 20:29, Nick Minutello <[hidden email]> 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 <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: JSON API: CamelCase or '_'?

Berkay Mollamustafaoglu-2
In reply to this post by mooky
+1 

Regards,
Berkay Mollamustafaoglu
mberkay on yahoo, google and skype


On Sat, Apr 3, 2010 at 3:29 PM, Nick Minutello <[hidden email]> 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 <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: JSON API: CamelCase or '_'?

Clinton Gormley
In reply to this post by mooky
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

> 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),
>
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


> 4. 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.

Reply | Threaded
Open this post in threaded view
|

Re: JSON API: CamelCase or '_'?

Sergio Bossa
In reply to this post by kimchy
On Sat, Apr 3, 2010 at 9:27 PM, Shay Banon <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: JSON API: CamelCase or '_'?

kimchy
Administrator
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 <[hidden email]> wrote:
On Sat, Apr 3, 2010 at 9:27 PM, Shay Banon <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: JSON API: CamelCase or '_'?

mooky
Youre such a conformist.... :P

On 4 April 2010 00:27, Shay Banon <[hidden email]> 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 <[hidden email]> wrote:
On Sat, Apr 3, 2010 at 9:27 PM, Shay Banon <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: JSON API: CamelCase or '_'?

dominict
In reply to this post by kimchy
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
Reply | Threaded
Open this post in threaded view
|

Re: JSON API: CamelCase or '_'?

Lukáš Vlček
In reply to this post by kimchy
Can't it simply support both?

Lukas

On Sat, Apr 3, 2010 at 8:25 PM, Shay Banon <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: JSON API: CamelCase or '_'?

kimchy
Administrator
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 <[hidden email]> wrote:
Can't it simply support both?

Lukas


On Sat, Apr 3, 2010 at 8:25 PM, Shay Banon <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: JSON API: CamelCase or '_'?

kimchy
Administrator
ok, committed, see: 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 <[hidden email]> 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 <[hidden email]> wrote:
Can't it simply support both?

Lukas


On Sat, Apr 3, 2010 at 8:25 PM, Shay Banon <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

Re: JSON API: CamelCase or '_'?

kimchy
Administrator
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 <[hidden email]> wrote:
ok, committed, see: 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 <[hidden email]> 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 <[hidden email]> wrote:
Can't it simply support both?

Lukas


On Sat, Apr 3, 2010 at 8:25 PM, Shay Banon <[hidden email]> 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