There are various reasons for this, amongst them:
- Bookmarks - I love the ability to drag and drop the browser address icon to my desktop to mark an important email.
- History - Looking through your history can be the quickest way to find an email you read half an hour ago. You need an encoded url to achieve this.
- App versioning - when rolling out a new version of an app (particularly if not all users are upgraded at once), a sub folder within the domain can be the most logical way to go about it (consider a guest user and a page on the old system for which you want to generate 404 in the new one).
- Referrals - If, for example, I get a percentage from each purchase that was made through me referring to Amazon; Amazon have to provide a url that I can copy and paste in a forum. You must have an encoded url for this.
- Cookie Disabled Browsing - to allow sites to work when cookies are disabled, the easiest method is to include an encrypted session id in the url.
- State - generally speaking, when the user session expires, a redirection to a password page will occur, but the user is expecting to return to the same screen before she was redirected. There are, however, other strategies to achieve this (albeit slightly more complicated from a programmer point of view).
- .htaccess - many site admins are very accustomed to this powerful tool, but its real power can only be realised if there are descriptive urls.
Google's URL is made of:
[Mail sub domain][App][Multiaccount ID][folder]
Where:
- [mail.google.com] means you are using the mail service of google.
- [App] is currently
/mail
, but you could also get there /a
in the past for google apps.
- [Multiaccount ID] ie
/u/0
facilitates the ability to log in with more than one email.
- [Folder] is the folder you are on, whether #inbox, #starred, etc. So you can target (or bookmark) a specific folder/label.
With Gmail, it also counts that google uses a one-login-for-any-google-site system. For that, cookies needs to be accessed, but they are only available for the exact domain which has set it. That's why any google product will redirect you to a nother shared url which stores the login details, and than redirect back to the app.
Problems with clear URL
Personally, I'm facing an opposite problem - I have a system that only uses the clean domain name and the rest is updated via ajax. The problem with this is that some users want to bookmark a page they access frequently - and can't.
Also, and from bitter experience, products like google analytics are useless without descriptive urls.
This is to an extent that on AJAX based sites that can work with only one clean url, the programmer is likely to search for the ability to update the address bar url without reloading the page, same like how GitHub works.