Multi-word resources

[Adrian Lynch]

I've asked my colleagues which they prefer:

☐ /passwordReset

☐ /password_reset

☐ /password-reset 

There's no conclusive answer. I saw it as a purely stylistic issue.

Are there any reasons to prefer one over the others?

Personally I like the "look" of /password-reset.

Thoughts?

Adrian

[Richard Mateosian]

Underscores can be hard to distinguish from spaces in URLs because URLs are often underlined.   ...RM

On Tue, Feb 24, 2015 at 7:20 AM, Adrian Lynch <adrian...@concreteplatform.com> wrote:

I've asked my colleagues which they prefer:

☐ /passwordReset

☐ /password_reset

☐ /password-reset 

--

Richard Mateosian <x...@pacbell.net>
Berkeley, California

[Chris Mullins]

Case sensitivity in URL's is interesting. 

Personally, I would prefer to see standard lower-camel-case used ("passwordReset"). In my opinion, this should also be the same as "passwordreset". 

My argument here is:

1. DNS itself is not case sensitive. We can argue over the historical context of why, but the facts are the facts. 

2. Given that DNS is case insensitive, I don't like have the path segments be case sensitive either. It always feels "weird" to say: "This part URL is case insensitive, but these other parts are not". 

3. Standard JSON is lower camel case. APIs seem to do quite a bit of JSON these days, and why have two standards? 

4. It's somewhat unusual to me to see an "_" in a path. Not that it doesn't happen, I just don't see it often. 

5. The "-" model, sometimes called snake-casing, is ok, but seems weird. Why have yet another casing standard in your API when just one would do? 

Cheers,

Chris

[Andriy Yurchuk]

Hi!

3. Standard JSON is lower camel case. APIs seem to do quite a bit of JSON these days, and why have two standards?

I was unable to find any notion of this in the JSON spec. What do you mean by the "Standard JSON"?

[Chris Mullins]

Google is your friend:

• Google JSON Casing. 
  

While it's not enshrined in a W3C, IEEE, or related spec, it's about as standard as it gets outside of that. 

Javascript developers in general are also very camelCase friendly, and a similar search to the above will give you endless reading material... :-) 

Cheers, 

Chris

[darrel...@gmail.com]

Chris,

As weird as it may seem the HTTP spec RFC 7230 explicitly says,

“The scheme and host are case-insensitive and normally provided in lowercase; all other components are compared in a case-sensitive manner.”

https://tools.ietf.org/html/rfc7230#section-2.7.3

Darrel

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

[Pedro Santos]

For me I've always prefered "hyphens-as-word-separators", reasons being:

• as was said, underscore can be mistakenly confused with a space in an underlined link
  
• lower camel case is (imo) less readable then either hyphen or underscores
• like was said domains and scheme and case insensitive, why break consistency?
• indexing/ranking engines usually interpret words seperated by underscores as a single word - try double clicking an underscore and hyphen separated word in chrome (made by google) and see the difference... (minus point for underscores)
  
• it's faster to write minor case and hyphens (I think in most if not on all keyboards) :-)
• case sensitivy can be an issue depending the server and how it's configured
• hypens are not a word character while underscore is (plus for hyphens)
• There are much more URIs out there using hyphens than underscores or camelCase/case sensitive ones (at least for the major players)
  

In the end, do what feels best for you, all three options are "legal" but from what I've seen there is no real complelling reason to go for one or another (at least that's my opinion regarding the reasons I listed, every one is "meh" ^_^ )