We have a database of resources, be they products, blog posts or something. We need to design a URL scheme to address them, for the public website.Here are two examples that are database ID bound:https://www.youtube.com/watch?v=7FPS6llqhXwhttp://www.amazon.co.uk/gp/product/B000NHOMSQHere's an example that's friendly:http://en.wikipedia.org/wiki/LED_circuit(A little glimpse into my browsing life there)I like the friendly URLs since you have an idea about what's on the end of the URL when you hover or see it in an email or document. It's better for SEO, or it used to be.What happens when the document or product is renamed? Either because it changed (Wiki may not change but our resources could) or due to a typo, right? Our resources are very technical, long words and error prone.Also, we have a database ID, which is a number. Let's look at an idea for an address of a video using a pretend rental store:http://vidsyeah.com/video/sliding-doors/287171The ID is obvious and is used in the DB look-up. Fine.The sliding-doors bit is non-unique and just generated from the video title, it could be verified on GET, so if gliding-doors was entered and doesn't match what's really in doc 287171 it responds 404.Or maybe it could be ignored, allowing humans to stick whatever they like in there, if someone ever cared to. So this URL would also work:http://vidsyeah.com/video/anything-at_all/287171The issue with verifying the friendly part is, as mentioned, the problem of renaming or typo correction. If the name changed, and in our domain that does happen, we don't want to break the URLs that are out there, so should we:Just not verify the friendly part.Verify, but add a 'history' of friendly parts to the database record so any previous friendly IDs still work!Your thoughts and ideas are welcome.Luke
Providing friendly URLs for a website vs. realities of database IDs
web applications;rest;web;websites;http