HTML5 History API and the Hashbang

BTI360 Blog / March 24, 2011 in 

One important concept in RESTful web services is the notion of “hypermedia as the engine of application state” or HATEOAS. This refers to a web resource being navigable through links, and maintaining application state through links. Another important concept is the accessibility of unique resources through unique URIs–retrieving specific information in the browser through GET calls. Ajax-enabled websites conform to these principles to varying degrees: for example, Google Maps will provide a link to any specific location on a map that a user visits, if it is requested, but does not enable a user to easily “retrace their steps” through multiple map manipulations, with links or through the back button. Other Ajax-enabled websites rely entirely on JavaScript to retrieve page content / resources: the browser first loads an empty webpage and JavaScript code, and this code then retrieves the main content through XHR calls (if this is the only way for a client to retrieve content from these providers, then these websites are not “RESTful”). These websites may be said to be following the (debatable) single page interface manifesto . In February, lifehacker.com had an error with its JavaScript code such that the entirety of its homepage failed to load. As mentioned in the Mike Davies blog posting, this error coincided with the introduction of the hashbang, #!, into its URLs. This character pair, formerly associated mostly with Perl and shell scripts, has become more common in URLs of websites like twitter and Facebook.

Web crawlers cannot automatically read content that is produced solely through Ajax loading.  The hashbang came into use because of Google–Google requested that a ‘!’ be added to existing # marks, as well as some other things specific for the Google web crawler, so that the crawler would take its own specific actions in order to find HTML snapshots (an additional requirement for the web content provider) on the newly Ajax-crawlable website.  The new use of #! provoked numerous comments ( here, here, here, here, and here) and questions, one of which could be: why are Ajax-heavy websites inserting fragments into their URLs, which are traditionally used as offsets into long single HTML pages?  The answer is that this allows the Ajax-loaded URL+fragment content to be bookmarked and to enable the back button; this use of the # symbol has been occurring since 2005, if not earlier.  This assumes that the website has been developed to reference the URL fragments it is attaching to URLs when first being loaded:  for example, if I navigate to the fictional Ajax-enabled map website www.myajaxmap.com/maps, which displays the United States upon its first page load, and I search for “Virginia”, which then manipulates the map into a view of Virginia (without reloading the entire page), then this fictional website could also modify the URL to be www.myajaxmap.com/maps#Virginia.  I can bookmark this view of the state, and then move on to other web pages.  However, once I navigate to my bookmark, since fragments are n

Previous

RESTful Client with the Play Framework

Next

Adding Gzip Support to Spring’s RestTemplate

Close Form

Enjoy our Blog?

Then stay up-to-date with our latest posts delivered right to your inbox.

  • This field is for validation purposes and should be left unchanged.

Or catch us on social media

Stay in Touch

Whether we’re honing our craft, hanging out with our team, or volunteering in the community, we invite you to keep tabs on us.

  • This field is for validation purposes and should be left unchanged.