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:

Any better suggestions?

  • 1
    It doesn't really matter. As long as you are consistent people won't mind. – ChrisF Jan 14 '14 at 15:20
  • 1
    Sticking to the way in which GET data works it would be + – tim.baker Jan 14 '14 at 16:14
  • 1
    If the URL is visible, it's not really an API. I suggest you modify the wording of your question in order to make that clear. I have retracted my close vote. – André Jan 14 '14 at 16:32
  • 6
    @virtualnobi even if it is never covered by a UI and is only used by humans when they're writing software calling the API, it still has a user experience, and that can still be improved. CLI programs have a UX, and so do APIs, and for that matter, so do toasters and bridges. If a human is using it to fulfil some task, it has a UX, even if it doesn't have a UI. – Racheet Jan 14 '14 at 16:37
  • 1
    Related: kalzumeus.com/2010/06/17/… – cimmanon Jan 14 '14 at 17:55

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.

| improve this answer | |
  • 1
    You won't come around changing name spellings. I don't know if having `O'Brien' in a URL is possible; re-converting it for inclusion into the URL after sanitation is probably too much trouble to be worth it. Most sites will probably come up with a schema to replace most nonword characters in names with something else when used in an URL, so why not dashes too. – Rumi P. Jan 14 '14 at 15:31
  • 1
    I've provided a reason why underscores are better than dashes. Dashes aren't a bad choice, for the reasons you mention. – Osvaldo Jan 14 '14 at 15:46

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.

| improve this answer | |
  • But this won't be easy to understand for non-programmers – Simon Arnold Jan 14 '14 at 16:10
  • 3
    @SimonArnold - True, but who are the ones that use APIs? Developers, right? – Code Maverick Jan 14 '14 at 16:12
  • A plus should also work: http://domain.com/api/user/firstname+lastname, which is arguably more understandable. – Andrew Leach Jan 14 '14 at 16:15
  • @AndrewLeach - Very true. I like that format too. I was just leaving an answer that shows how you can leave the space. – Code Maverick Jan 14 '14 at 16:17

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.


| improve this answer | |
  • I like this one, though I'd probably reverse the name order to lastname/firstname. It seems to fit the hierarchy of paths better somehow. – André Jan 14 '14 at 16:34
  • @André so you put the last name first and the first name last? – Pierre Arlaud Jan 14 '14 at 16:42
  • 1
    @ArlaudPierre: in a context like this, yes. Just like you'd find them in a phone book, by the way. – André Jan 14 '14 at 17:07
  • @André If you do it that way round, you imply a relationship between people that have the same last name, even if they're not connected. Since they're in the same folder. It makes sense to me to have a folder of all "Johns" distinguished by their last names, it makes less sense to have a folder of all "Smiths" if those people are not actually part of the same family. – Racheet Mar 6 '14 at 18:26

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:
E. Fred
E Fred

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.

| improve this answer | |

Per RFC1738 your candidate characters are


I'd choose "+".


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.

| improve this answer | |
  • 1
    The only issue with doing it this way is that if your firstname and/or lastname had spaces in it, then you'd have multiple + occurrences. How would the code know which part belongs with which name? Look at the 2nd part of my answer for a solution to that. – Code Maverick Jan 14 '14 at 17:32
  • 1
    Yes you are correct. Essentially all escapable (including non-ASCII) characters are subject to this. I think the OP has to figure out what kind of cake he should make if he wants to eat it too. – broc.seib Jan 14 '14 at 17:42

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.

| improve this answer | |

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

| improve this answer | |
  • 1
    But what if I have to make a reference to someone like J.K. Rowling? – Simon Arnold Jan 14 '14 at 15:25
  • 4
    Why is the perceived chunkiness of the separator a factor here? – JonW Jan 14 '14 at 15:27
  • @SimonArnold Isn't it supposed to be a first name or a middle name? J.K. is not a first name. – Pierre Arlaud Jan 14 '14 at 16:10
  • Yes, but I'm worried about people who have multiple firstname or uncommun firstname that everybody shorten. Like who know who is Joanne Rowling? But everyone know who is J.K. Rowling, right? – Simon Arnold Jan 14 '14 at 16:16
  • Could you expand on this answer please? As it stands, it does not really explain where the cluncky-ness comes from, or who is perceiving it this way. As it stands, this answer is a candidate for removal. – André Jan 14 '14 at 16:29

Not the answer you're looking for? Browse other questions tagged or ask your own question.