Creating RESTful Websites with meaningful URLs
REST is a big buzzword these days and creating RESTful sites is a requirement for a lot of new projects. Creating a RESTful website requires attention to HTTP headers, HTTP response codes, stateless URLs, and the design of your URL structure. This post is going to focus on the design of URLs.
It’s important when designing a new project that the URL structure is planned ahead of any development work being done to keep from having to redo work or create inefficient or awkward workarounds. The URL should give your users an indication of where they are in the site, should be human readable and linking to the URL should give your user the same outcome every time they access the page.
To design your URL structure, identify the pieces of information you use on your site and order those pieces of information from most general to most specific to create your URL structure*. Run through different examples using different content types to make sure your URL structure works across your content, not just for isolated examples. The more diverse your test urls and the more examples you test, the more effectively you’ll design your URL.
Consider the example of a website about entertainment venues: if your user wants to view information about a particular restaurant, he may need to identify the following information first: country, state, city, type of venues, genre and neighbourhood. So your URL structure may look like: http://www.ThingsToDo.com/australia/nsw/sydney/restuarants/thai/cbd/My-Thai. Based on this example, your URL structure would be: http://www.ThingToDo.com/{country}/{state}/{city}/{type-of-entertainment}/{genre}/{neighborhood}/{name-of-venue}.
Would this work if your user was looking for an F1 race in London? http://www.ThingToDo.com/England/{state}/London/Cars/F1/. England doesn’t have states, but rather regions and regions are usually not always used. “F1” may also not have neighbourhoods or venue names like restaurants. You’ll need to consider what to do in these cases. For the state, options may be to change {state} to {region}, identify if that field is really necessary or have state/region used or not used based on the country. By going through this exercise, you not only do the forward planning for your site structure, but you start designing the logic of your site, which when well thought out significantly decreases development time.
Let’s return to the example of the Thai restaurant. The user on that page can look at the URL and know exactly what type of content they can expect on that page and if they wish could easily change “Sydney” to “Melbourne” in the URL and get a different yet relevant result. Alternatively, they may decide they don’t want to narrow the results by CBD, so they may remove “cbd/My-Thai”, which would return a list of neighbourhoods for them to choose from. Contrast this with using internal ids for the different pieces of information, e.g., 1 for Australia and 34 instead of Sydney; the user would neither have the ability to move around the site as easily nor ability to know the content of the page if they received the link from a friend or bookmarked the page.
An added benefit of this type of URL structure is it carries a lot of weight in SEO (search engine optimisation) and can increase your position in search results displayed in search engines like Google and Yahoo, which can save money in advertising and SEO campaigns.
RESTful web design requires attention to many different elements of site design, one piece being URL structure. Getting the URL structure right before starting development helps organise the content of your site, gives your users the best possible user experience, saves you money and improves your ranking in search results.
* If you’re designing an API, your first category should be version, since your API will most likely change.
