What should replace a space in a api url? [closed]

Question

I am creating an API, where we can make reference to the users with their firstname and lastname. Since I can't use space, what is the best way to separate the firstname and lastname in the url?

I was thinking about using underscore, like this:
http://example.com/api/user/firstname_lastname

Any better suggestions?

Answer 1

Generally sites use either underscore or dash to replace a space in the URL. Underscore may be better because some persons have a dash in their name.

Consistency is also important. Don't use dash sometimes and underscore other times.

Answer 2

If you really wanted to keep the space, you could HTML Encode it.

The result would be: http://domain.com/api/user/firstname%20lastname

Then all you'd have to do is HTML Decode it and you have your complete name.

---

@AndrewLeach's comment got me thinking, you might need to use a combination of + and %20. A first and/or last name could have spaces in and of itself. For example, Bobby Ray Johnson Jr. You'd have a space in between Bobby Ray and between Johnson and Jr.

The result would be: http://domain.com/api/user/bobby%20ray+johnson%20jr

Doing it this way, a developer could HTML Decode the whole name and then split on the + creating an array of two strings, firstname and lastname, which would already have the spaces retained.

Answer 3

If your api is RESTful or even RESTlike can't you just seperate them out into their own fields?

That way, you'd seperate them out with a "/" character the same way you seperate out the user field and everything else in your api.

This approach is the current convention in web api design.

i.e.:

http://domain.com/api/user/firstname/lastname

Answer 4

Your question made me join UX! UI is one of my biggest pet peeves of programming. And in the 20+ years I have been writing code, the single most consistent problem.

The question doesn't give me enough context to weigh in too heavily about the technology you are using or are allowed but I'm assuming the platform includes Windows.

The best I have seen presented thus far is domain.com/name/name

Character encoding is definitely going to bite you somewhere as it did me. My application to import customer records and information into Quickbooks has mangled names for a decade and I never got to the bottom of it until the most recent go at it when a few records would refuse to import. I go on a lot about this below...

Allow for name changing. I have some customers who gave us their name 4 or 5 different ways, and that doesn't include the Pat/Patrick like cases. We are keying everyone on their email addresses, which isn't perfect but about the best we could come up with. IMHO, force people with an OpenId or Google login. The Google is in everyone's lives and only a few are completely without a Google account.

Last, First - zip is what we ended up deciding upon for our Quickbooks "customer name" and I do lots of work around eliminating any spaces outside of the " - " separator. Then as we encounter a customer that moved or name is different, we change that account's name to Last, First - OLD and may or may not later go back and merge the customers (historically requires Single User mode). Of all the things we tried, this best helps telephone support with Quickbooks as the operator's sole tool. With our web app, we can search on anything.

---

Spend more time on input validation & handling

Spaces in URLs are handled almost automagically, so to me this is the least of your worries. Worry about the space people and work more extra hours for handling these. There are McDonalds and Mc Donalds type entries from my customers. And van Name or Name von Name customers too.

First/Last ordering doesn't matter really, so long as that customer is consistent. You can specify Last/First and anyone currently in China or Korea will always flip those.

Always strip leading and trailing spaces. I know about this and still find I often enter my name on forms as Chris_ and Kelley.

Never discount E. E. Cummings type names, they're about as frequent as O'Brians but less consistent. There are also people who use their middle name, like E. Fred Johnson.

Ultimately, take whatever the user types and do your best to come up with a rule. If you do magic with their input at least warn them what their login is and/or give them approval or choices:

Hi E. Fred,

Your login is based on your name and we want to make sure you use the login the same way you use and type your name in everyday life; please pick the option you wish to have as your login. Don't worry, you can change it later, too:
✔ Fred
☐ E. Fred
☐ E Fred
☐ EFred

O'Brians are prevalent and also come as:
O'Brian _{typed on my US keyboard}
O´Brian _{with acute accent U+00B4 (This is a great link for the quotes)}
O’Brian _{with U+2019 directed closing single quote}
O`Brian _{with grave accent U+0060}
O Brian and OBrian happens when customers have already been punished by technology for their name.

When it comes to the single quotes, the next time I'm programming the front end on a web app (hopefully never again), I'll detect for all single quotes not ' from us keyboard and then make a whole special dialog for handling this and reminding the user about that symbol possibly not being found on keyboards in other countries and then force them to the ' from us keyboard and/or putting in effort to see if their keyboard can type those.

Accented characters: As a very user-sympathetic programmer, I hate to say it but my recommendation is to be ethnocentric and drop tilde ñ and umlat Ö accented characters, as I described in my Server Fault answer. The discussion about how to handle these might be as expansive as the rest of my rant/missive above. To be the most polite, you can store their UTF-8 encoded original entry and use it for comparison and/or display elsewhere in the application.

Answer 5

Per RFC1738 your candidate characters are

$-_.+!*'(),

I'd choose "+".

http://domain.com/api/user/firstname+lastname

Encoders used the "+" character as a replacement for a space character in the early days, and many still do, though I think the official spec calls for using %20 now. I think dot, dash, and underscore have aesthetic value too.

A note of caution: if you permit names that use UTF-8 characters, you have to encode them, losing their aesthetic. See RFC3986:

Non-ASCII characters must first be encoded according to UTF-8 [STD63], and then each octet of the corresponding UTF-8 sequence must be percent- encoded to be represented as URI characters. URI producing applications must not use percent-encoding in host unless it is used to represent a UTF-8 character sequence.

Answer 6

To get this to work properly, underscore _ is the language independent (ASCII) character to use. The dash (which I love to use) doesn't match in all character encoding languages.

I've implemented a string.replace() of no less than seven different dashes imported from XML to a product database. I don't want seven different products depending on dash character encoding. That's why underscore is correct.

But also, this depends on context. If you want to signal different words, and don't care which dash of dashes it is, use dash.

If you use an underscore '_' character, then Google will combine the two words on either side into one word. So bla.com/kw1_kw2.html wouldn't show up by itself for kw1 or kw2. You'd have to search for kw1_kw2 as a query term to bring up that page.

And Jeff Atwood wrote in his article Of Spaces, Underscores and Dashes that:

As you can see (on character in different languages), the dash is not matched, but underscore is. This_is_a_single_word, but this-is-multiple-words.

Like NutraSweet and Splenda, neither is really an acceptable substitute for a space, but we might as well follow the established convention instead of inventing our own.

To Conclude

If your not sure, and are in the context of programming - use underscore! If you want to signal different words (to Google Analytics as one example) use dash.

Answer 7

I'd use a period character, it's a little less chunky looking than an underscore.