Why JSON API Specification suggest use of hyphen/minus to separate words in member names?
up vote
6
down vote
favorite
According to recommendation on JSON API specification site, we should use all lower case member names in JSON separated by hyphens:
The allowed and recommended characters for an URL safe naming of
members are defined in the format spec. To also standardize member
names, the following (more restrictive) rules are recommended:
Member names SHOULD start and end with the characters "a-z" (U+0061 to
U+007A) Member names SHOULD contain only the characters "a-z" (U+0061
to U+007A), "0-9" (U+0030 to U+0039), and the hyphen minus (U+002D
HYPHEN-MINUS, "-") as separator between multiple words.
So basically, we should be using JSON like this:
"first-name": "Jason",
"last-name": "Tough"
Would not it make it cumbersome to access those properties in JavaScript? Or any other programming language for that matter, especially if we want to generate classes from JSON Schema?
What is the motivation behind this recommendation?
javascript json rest jsonschema
edited May 23 '17 at 12:19
Community♦
11
asked Feb 4 '16 at 3:06
Sebastian K
4,25013156
|
show 3 more comments
up vote
6
down vote
favorite
According to recommendation on JSON API specification site, we should use all lower case member names in JSON separated by hyphens:
The allowed and recommended characters for an URL safe naming of
members are defined in the format spec. To also standardize member
names, the following (more restrictive) rules are recommended:
Member names SHOULD start and end with the characters "a-z" (U+0061 to
U+007A) Member names SHOULD contain only the characters "a-z" (U+0061
to U+007A), "0-9" (U+0030 to U+0039), and the hyphen minus (U+002D
HYPHEN-MINUS, "-") as separator between multiple words.
So basically, we should be using JSON like this:
"first-name": "Jason",
"last-name": "Tough"
Would not it make it cumbersome to access those properties in JavaScript? Or any other programming language for that matter, especially if we want to generate classes from JSON Schema?
What is the motivation behind this recommendation?
javascript json rest jsonschema
edited May 23 '17 at 12:19
Community♦
11
asked Feb 4 '16 at 3:06
Sebastian K
4,25013156
1
It explains the motivation: to use characters that are safe in a URL.
– Barmar
Feb 4 '16 at 3:16
2
Yeah. That spec is stupid because underscore (_) is a url safe character. I guess 1. they thought using-saves them from typing shift and 2. they're not javascript programmers so have never used thefoo.barsyntax much. Any JSON specification that does not make javascript usage a priority is bound to fail
– slebetman
Feb 4 '16 at 3:34
i would not describe array syntax or template expressions as "very cumbersome".
– dandavis
Feb 4 '16 at 4:04
It is worth mentioning that other recommendations such as CamelCase (mostly Java) is also widely used sofirstNameandlast-nameandanObjectWithAttributteFooBarare seen... The thing is, since legacy system do not have common rules, they are usually used until they start glitching, and people create a new standard to solve major issues...
– Bonatti
Jun 2 '16 at 14:24
What alternative would you propose? I like lower-case everything because it means one less step when dealing with user-input. I like-because_is difficult to read sometimes and, as lazy as this sound,_requires pressingshiftwhere-does not.
– IMTheNachoMan
Jun 2 '16 at 14:25
|
show 3 more comments
up vote
6
down vote
favorite
up vote
6
down vote
favorite
According to recommendation on JSON API specification site, we should use all lower case member names in JSON separated by hyphens:
The allowed and recommended characters for an URL safe naming of
members are defined in the format spec. To also standardize member
names, the following (more restrictive) rules are recommended:
Member names SHOULD start and end with the characters "a-z" (U+0061 to
U+007A) Member names SHOULD contain only the characters "a-z" (U+0061
to U+007A), "0-9" (U+0030 to U+0039), and the hyphen minus (U+002D
HYPHEN-MINUS, "-") as separator between multiple words.
So basically, we should be using JSON like this:
"first-name": "Jason",
"last-name": "Tough"
Would not it make it cumbersome to access those properties in JavaScript? Or any other programming language for that matter, especially if we want to generate classes from JSON Schema?
What is the motivation behind this recommendation?
javascript json rest jsonschema
edited May 23 '17 at 12:19
Community♦
11
asked Feb 4 '16 at 3:06
Sebastian K
4,25013156
According to recommendation on JSON API specification site, we should use all lower case member names in JSON separated by hyphens:
The allowed and recommended characters for an URL safe naming of
members are defined in the format spec. To also standardize member
names, the following (more restrictive) rules are recommended:
Member names SHOULD start and end with the characters "a-z" (U+0061 to
U+007A) Member names SHOULD contain only the characters "a-z" (U+0061
to U+007A), "0-9" (U+0030 to U+0039), and the hyphen minus (U+002D
HYPHEN-MINUS, "-") as separator between multiple words.
So basically, we should be using JSON like this:
"first-name": "Jason",
"last-name": "Tough"
Would not it make it cumbersome to access those properties in JavaScript? Or any other programming language for that matter, especially if we want to generate classes from JSON Schema?
What is the motivation behind this recommendation?
javascript json rest jsonschema
javascript json rest jsonschema
edited May 23 '17 at 12:19
Community♦
11
asked Feb 4 '16 at 3:06
Sebastian K
4,25013156
edited May 23 '17 at 12:19
Community♦
11
asked Feb 4 '16 at 3:06
Sebastian K
4,25013156
edited May 23 '17 at 12:19
Community♦
11
edited May 23 '17 at 12:19
Community♦
11
edited May 23 '17 at 12:19
Community♦
11
11
asked Feb 4 '16 at 3:06
Sebastian K
4,25013156
asked Feb 4 '16 at 3:06
Sebastian K
4,25013156
asked Feb 4 '16 at 3:06
Sebastian K
4,25013156
4,25013156
1
It explains the motivation: to use characters that are safe in a URL.
– Barmar
Feb 4 '16 at 3:16
2
Yeah. That spec is stupid because underscore (_) is a url safe character. I guess 1. they thought using-saves them from typing shift and 2. they're not javascript programmers so have never used thefoo.barsyntax much. Any JSON specification that does not make javascript usage a priority is bound to fail
– slebetman
Feb 4 '16 at 3:34
i would not describe array syntax or template expressions as "very cumbersome".
– dandavis
Feb 4 '16 at 4:04
It is worth mentioning that other recommendations such as CamelCase (mostly Java) is also widely used sofirstNameandlast-nameandanObjectWithAttributteFooBarare seen... The thing is, since legacy system do not have common rules, they are usually used until they start glitching, and people create a new standard to solve major issues...
– Bonatti
Jun 2 '16 at 14:24
What alternative would you propose? I like lower-case everything because it means one less step when dealing with user-input. I like-because_is difficult to read sometimes and, as lazy as this sound,_requires pressingshiftwhere-does not.
– IMTheNachoMan
Jun 2 '16 at 14:25
|
show 3 more comments
1
It explains the motivation: to use characters that are safe in a URL.
– Barmar
Feb 4 '16 at 3:16
2
Yeah. That spec is stupid because underscore (_) is a url safe character. I guess 1. they thought using-saves them from typing shift and 2. they're not javascript programmers so have never used thefoo.barsyntax much. Any JSON specification that does not make javascript usage a priority is bound to fail
– slebetman
Feb 4 '16 at 3:34
i would not describe array syntax or template expressions as "very cumbersome".
– dandavis
Feb 4 '16 at 4:04
It is worth mentioning that other recommendations such as CamelCase (mostly Java) is also widely used sofirstNameandlast-nameandanObjectWithAttributteFooBarare seen... The thing is, since legacy system do not have common rules, they are usually used until they start glitching, and people create a new standard to solve major issues...
– Bonatti
Jun 2 '16 at 14:24
What alternative would you propose? I like lower-case everything because it means one less step when dealing with user-input. I like-because_is difficult to read sometimes and, as lazy as this sound,_requires pressingshiftwhere-does not.
– IMTheNachoMan
Jun 2 '16 at 14:25
1
1
It explains the motivation: to use characters that are safe in a URL.
– Barmar
Feb 4 '16 at 3:16
It explains the motivation: to use characters that are safe in a URL.
– Barmar
Feb 4 '16 at 3:16
2
2
Yeah. That spec is stupid because underscore (
_) is a url safe character. I guess 1. they thought using - saves them from typing shift and 2. they're not javascript programmers so have never used the foo.bar syntax much. Any JSON specification that does not make javascript usage a priority is bound to fail– slebetman
Feb 4 '16 at 3:34
Yeah. That spec is stupid because underscore (
_) is a url safe character. I guess 1. they thought using - saves them from typing shift and 2. they're not javascript programmers so have never used the foo.bar syntax much. Any JSON specification that does not make javascript usage a priority is bound to fail– slebetman
Feb 4 '16 at 3:34
i would not describe array syntax or template expressions as "very cumbersome".
– dandavis
Feb 4 '16 at 4:04
i would not describe array syntax or template expressions as "very cumbersome".
– dandavis
Feb 4 '16 at 4:04
It is worth mentioning that other recommendations such as CamelCase (mostly Java) is also widely used so
firstName and last-name and anObjectWithAttributteFooBar are seen... The thing is, since legacy system do not have common rules, they are usually used until they start glitching, and people create a new standard to solve major issues...– Bonatti
Jun 2 '16 at 14:24
It is worth mentioning that other recommendations such as CamelCase (mostly Java) is also widely used so
firstName and last-name and anObjectWithAttributteFooBar are seen... The thing is, since legacy system do not have common rules, they are usually used until they start glitching, and people create a new standard to solve major issues...– Bonatti
Jun 2 '16 at 14:24
What alternative would you propose? I like lower-case everything because it means one less step when dealing with user-input. I like
- because _ is difficult to read sometimes and, as lazy as this sound, _ requires pressing shift where - does not.– IMTheNachoMan
Jun 2 '16 at 14:25
What alternative would you propose? I like lower-case everything because it means one less step when dealing with user-input. I like
- because _ is difficult to read sometimes and, as lazy as this sound, _ requires pressing shift where - does not.– IMTheNachoMan
Jun 2 '16 at 14:25
|
show 3 more comments
2 Answers
2
active
oldest
votes
up vote
2
down vote
I have had the same question about that, i found this explanation about why i shouldn't use a underscore with namingDirectives. it's not the same but it looks pretty similar:
The UNDERSCORE character ("_") may be used in filenames and directory names where an application (unavoidably) generates this character, but in general, use of HYPHEN to mark juncture is preferable; the UNDERSCORE character may be visually confused with SPACE or an underline-effect in some predictable publication contexts. An UNDERSCORE must never be used in a filename or directory name that is used in a document URI — that is, a primary URI reference published as a document cover page URI (i.e. as required for identification of a Work Product as a whole or for identification of a separately-titled prose Part in a Multi-Part Work Product).
answered Jun 2 '16 at 14:19
Charly Palencia
15718
2
But this is a very weak argument in this context. It's JSON data to be transmitted over the network, not some whitepaper.
– slebetman
Jul 22 '16 at 1:20
add a comment |
up vote
0
down vote
Looks like JSONAPI naming from the quote in question is no longer valid. Currently the `JSONAPI recommends:
Naming
The specification places certain hard restrictions on how members
(i.e., keys) in a JSON:API document may named. To further standardize
member names, which is especially important when mixing profiles
authored by different parties, the following rules are also
recommended:Member names SHOULD be camel-cased (i.e., wordWordWord)
Member names SHOULD start and end with a character “a-z” (U+0061 to U+007A)
Member names SHOULD contain only ASCII alphanumeric characters (i.e., “a-z”, “A-Z”, and “0-9”)
so above example should be:
"firstName": "Jason",
"lastName": "Tough"
answered Nov 10 at 11:04
ToTenMilan
98311
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
I have had the same question about that, i found this explanation about why i shouldn't use a underscore with namingDirectives. it's not the same but it looks pretty similar:
The UNDERSCORE character ("_") may be used in filenames and directory names where an application (unavoidably) generates this character, but in general, use of HYPHEN to mark juncture is preferable; the UNDERSCORE character may be visually confused with SPACE or an underline-effect in some predictable publication contexts. An UNDERSCORE must never be used in a filename or directory name that is used in a document URI — that is, a primary URI reference published as a document cover page URI (i.e. as required for identification of a Work Product as a whole or for identification of a separately-titled prose Part in a Multi-Part Work Product).
answered Jun 2 '16 at 14:19
Charly Palencia
15718
2
But this is a very weak argument in this context. It's JSON data to be transmitted over the network, not some whitepaper.
– slebetman
Jul 22 '16 at 1:20
add a comment |
up vote
2
down vote
I have had the same question about that, i found this explanation about why i shouldn't use a underscore with namingDirectives. it's not the same but it looks pretty similar:
The UNDERSCORE character ("_") may be used in filenames and directory names where an application (unavoidably) generates this character, but in general, use of HYPHEN to mark juncture is preferable; the UNDERSCORE character may be visually confused with SPACE or an underline-effect in some predictable publication contexts. An UNDERSCORE must never be used in a filename or directory name that is used in a document URI — that is, a primary URI reference published as a document cover page URI (i.e. as required for identification of a Work Product as a whole or for identification of a separately-titled prose Part in a Multi-Part Work Product).
answered Jun 2 '16 at 14:19
Charly Palencia
15718
2
But this is a very weak argument in this context. It's JSON data to be transmitted over the network, not some whitepaper.
– slebetman
Jul 22 '16 at 1:20
add a comment |
up vote
2
down vote
up vote
2
down vote
I have had the same question about that, i found this explanation about why i shouldn't use a underscore with namingDirectives. it's not the same but it looks pretty similar:
The UNDERSCORE character ("_") may be used in filenames and directory names where an application (unavoidably) generates this character, but in general, use of HYPHEN to mark juncture is preferable; the UNDERSCORE character may be visually confused with SPACE or an underline-effect in some predictable publication contexts. An UNDERSCORE must never be used in a filename or directory name that is used in a document URI — that is, a primary URI reference published as a document cover page URI (i.e. as required for identification of a Work Product as a whole or for identification of a separately-titled prose Part in a Multi-Part Work Product).
answered Jun 2 '16 at 14:19
Charly Palencia
15718
I have had the same question about that, i found this explanation about why i shouldn't use a underscore with namingDirectives. it's not the same but it looks pretty similar:
The UNDERSCORE character ("_") may be used in filenames and directory names where an application (unavoidably) generates this character, but in general, use of HYPHEN to mark juncture is preferable; the UNDERSCORE character may be visually confused with SPACE or an underline-effect in some predictable publication contexts. An UNDERSCORE must never be used in a filename or directory name that is used in a document URI — that is, a primary URI reference published as a document cover page URI (i.e. as required for identification of a Work Product as a whole or for identification of a separately-titled prose Part in a Multi-Part Work Product).
answered Jun 2 '16 at 14:19
Charly Palencia
15718
answered Jun 2 '16 at 14:19
Charly Palencia
15718
answered Jun 2 '16 at 14:19
Charly Palencia
15718
answered Jun 2 '16 at 14:19
Charly Palencia
15718
15718
2
But this is a very weak argument in this context. It's JSON data to be transmitted over the network, not some whitepaper.
– slebetman
Jul 22 '16 at 1:20
add a comment |
2
But this is a very weak argument in this context. It's JSON data to be transmitted over the network, not some whitepaper.
– slebetman
Jul 22 '16 at 1:20
2
2
But this is a very weak argument in this context. It's JSON data to be transmitted over the network, not some whitepaper.
– slebetman
Jul 22 '16 at 1:20
But this is a very weak argument in this context. It's JSON data to be transmitted over the network, not some whitepaper.
– slebetman
Jul 22 '16 at 1:20
add a comment |
up vote
0
down vote
Looks like JSONAPI naming from the quote in question is no longer valid. Currently the `JSONAPI recommends:
Naming
The specification places certain hard restrictions on how members
(i.e., keys) in a JSON:API document may named. To further standardize
member names, which is especially important when mixing profiles
authored by different parties, the following rules are also
recommended:Member names SHOULD be camel-cased (i.e., wordWordWord)
Member names SHOULD start and end with a character “a-z” (U+0061 to U+007A)
Member names SHOULD contain only ASCII alphanumeric characters (i.e., “a-z”, “A-Z”, and “0-9”)
so above example should be:
"firstName": "Jason",
"lastName": "Tough"
answered Nov 10 at 11:04
ToTenMilan
98311
add a comment |
up vote
0
down vote
Looks like JSONAPI naming from the quote in question is no longer valid. Currently the `JSONAPI recommends:
Naming
The specification places certain hard restrictions on how members
(i.e., keys) in a JSON:API document may named. To further standardize
member names, which is especially important when mixing profiles
authored by different parties, the following rules are also
recommended:Member names SHOULD be camel-cased (i.e., wordWordWord)
Member names SHOULD start and end with a character “a-z” (U+0061 to U+007A)
Member names SHOULD contain only ASCII alphanumeric characters (i.e., “a-z”, “A-Z”, and “0-9”)
so above example should be:
"firstName": "Jason",
"lastName": "Tough"
answered Nov 10 at 11:04
ToTenMilan
98311
add a comment |
up vote
0
down vote
up vote
0
down vote
Looks like JSONAPI naming from the quote in question is no longer valid. Currently the `JSONAPI recommends:
Naming
The specification places certain hard restrictions on how members
(i.e., keys) in a JSON:API document may named. To further standardize
member names, which is especially important when mixing profiles
authored by different parties, the following rules are also
recommended:Member names SHOULD be camel-cased (i.e., wordWordWord)
Member names SHOULD start and end with a character “a-z” (U+0061 to U+007A)
Member names SHOULD contain only ASCII alphanumeric characters (i.e., “a-z”, “A-Z”, and “0-9”)
so above example should be:
"firstName": "Jason",
"lastName": "Tough"
answered Nov 10 at 11:04
ToTenMilan
98311
Looks like JSONAPI naming from the quote in question is no longer valid. Currently the `JSONAPI recommends:
Naming
The specification places certain hard restrictions on how members
(i.e., keys) in a JSON:API document may named. To further standardize
member names, which is especially important when mixing profiles
authored by different parties, the following rules are also
recommended:Member names SHOULD be camel-cased (i.e., wordWordWord)
Member names SHOULD start and end with a character “a-z” (U+0061 to U+007A)
Member names SHOULD contain only ASCII alphanumeric characters (i.e., “a-z”, “A-Z”, and “0-9”)
so above example should be:
"firstName": "Jason",
"lastName": "Tough"
answered Nov 10 at 11:04
ToTenMilan
98311
answered Nov 10 at 11:04
ToTenMilan
98311
answered Nov 10 at 11:04
ToTenMilan
98311
answered Nov 10 at 11:04
ToTenMilan
98311
98311
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f35191756%2fwhy-json-api-specification-suggest-use-of-hyphen-minus-to-separate-words-in-memb%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
It explains the motivation: to use characters that are safe in a URL.
– Barmar
Feb 4 '16 at 3:16
2
Yeah. That spec is stupid because underscore (
_) is a url safe character. I guess 1. they thought using-saves them from typing shift and 2. they're not javascript programmers so have never used thefoo.barsyntax much. Any JSON specification that does not make javascript usage a priority is bound to fail– slebetman
Feb 4 '16 at 3:34
i would not describe array syntax or template expressions as "very cumbersome".
– dandavis
Feb 4 '16 at 4:04
It is worth mentioning that other recommendations such as CamelCase (mostly Java) is also widely used so
firstNameandlast-nameandanObjectWithAttributteFooBarare seen... The thing is, since legacy system do not have common rules, they are usually used until they start glitching, and people create a new standard to solve major issues...– Bonatti
Jun 2 '16 at 14:24
What alternative would you propose? I like lower-case everything because it means one less step when dealing with user-input. I like
-because_is difficult to read sometimes and, as lazy as this sound,_requires pressingshiftwhere-does not.– IMTheNachoMan
Jun 2 '16 at 14:25