Published: 01/18/2016

I love working with the web, there is so much to know and learn about web development. Have you ever thought about the URL? I recently learned quite a bit about the URL. The URL is composed primarily of a few things:

  1. The Scheme, which is followed by the “://”. This is typically http, https or ftp. Others such as file:// are also valid.
  2. You can also supply user name and password “user:password@”
  3. There is the host:port, which could be something like localhost:3000
  4. Then we have the path, such as /api/v1/news_feed
  5. Finally we have the query parameter, such as ?id=5&name=”adam”.
  6. The fragment identifier is the “#” in the URL. This is client side only and is not sent to the server. The fragment can be used for client routing or for client specific behavior or specifically to link to a certain location in a document.
  7. All of 1 – 5 are sent to the server. List item 6 is not sent to the server.

#6 is really interesting and new to me. I’ve never thought about a URL having two componets, client side and server side. It’s really cleaver and genius. What this raises is issues with a SPA framework however. The whole issue comes down to client vs server behavior, the “clean”, “marketing friendly” urls that don’t rely on the hash tag are always sent to the server. This is why you need mod-rewrite rules in apache. Everytime you navigate in a SPA, all of the url before the fragment identifier is sent to the server. The server has to ignore all the of these client specific urls. This adds a lot of complexitity and unneeded overhead in dealing with your SPA application. A better approach is for server invoked behavior, use the part of the URI before the fragement identifier, and for the client specific behavior, use the space after the fragment identifier.

Resources: