How to show Ajax requests in URL?

For the demo linked in your question, achieving that functionality is actually really simple - as it doesn't use any AJAX at all (when you start to add AJAX to the mix, it get's more difficult - explained later). To achieve that functionality you would; upgrade your links to use hashes, then bind into the hashchange event. Unfortunately the hashchange event is not cross-browser compatible, though luckily there are many "history/remote plugins" available - our preferred one over the years has proven to be jQuery History, it's open-source, got great support and is actively developed :-).

Although, when it comes to adding AJAX functionality to the mix like such sites as Facebook, WBHomes and Balupton.com then you will start to face a whole series of seriously difficult problems! (I know as I was the lead architect for the last two sites!). Some of these problems are:

• How to gracefully and easily upgrade certain internal links to use the History and AJAX functionality, and detect when the hash has changed? while keeping other links working just like before.
• How to redirect from "www.yoursite.com/myapp/a/b/c" to "www.yoursite.com/myapp/#/a/b/c"? and still keep the experience smooth for the user such that the 3 necessary redirects are as smooth as possible.
• How to submit form values and data using AJAX and update the hash? and vice versa if they don't support Javascript.
• How to detect which particular area of the page the AJAX request is wanting? Such that subpages are displayed with the correct page.
• How to change the page title when the AJAX state changes? and other non-page content.
• How to perform nice intro/outro effects while the AJAX state loads and changes? such that the user isn't left in the dark.
• How to update the sidebar login info when we login via AJAX? As obviously we don't want that login button up the top left to be there anymore.
• How to still support the website for users that do not have JS enabled? Such that it gracefully degrades and still is indexable by Search Engines.

The only open-source and reliable project I know of which tries to solve all those extremely difficult problems mentioned has proven to be jQuery Ajaxy. It's effectively an extension to the jQuery History project mentioned before, providing a nice elegant high level interface to add AJAX functionality to the mix to take care of those difficult problems behind the scenes so we don't have to worry about them. It's also the chosen solution used in the last few commercial sites mentioned earlier.

Good luck, and if you have any further questions then just post a comment on this answer and I'll get to it asap :-)

Update: There is now the HTML5 History API (pushState, popState) which deprecates the HTML4 hashchange functionality. History.js is now the sucessor to jQuery History and provides cross-browser compatibility for the HTML5 History API and an optional hashchange fallback for HTML4 browsers. jQuery Ajaxy will be upgraded for History.js

Ajax requests have usually a X-Requested-With: XMLHttpRequest request header. In JSF, you can obtain the request headers by ExternalContext#getRequestHeaderMap().

ExternalContext externalContext = facesContext.getExternalContext();
Map<String, String> headers = externalContext.getRequestHeaderMap();
boolean ajax = "XMLHttpRequest".equals(headers.get("X-Requested-With"));

First, keep in mind that the server itself might not return responses in the order the requests are received. Imagine if you fire a complicated ajax request first, and a simple on second (perhaps referencing some cached static data). The second request will probably return before the complicated one returns. You can see how this complicates things; if the order the requests are received is not the same as the order the responses come back, how can one make assurances?

You have some options:

1) You can make the requests synchronous instead of asynchronous. However, this will lock up the browser.

2) A better approach would be to chain the requests such that the next request only fires after the first is completed, by only firing the second request after the first returns.

As a note, if you find that you have 2 ajax operations that you need to chain, it might make sense to create a server endpoint to handle the 2 operations in one request. i.e., just make an ajax request to do everything you need.