Designing Effective URLs: Understanding URI, URL, URN and Best Practices
This article explains the differences between URI, URL and URN, outlines best‑practice principles for designing stable, readable and user‑friendly URLs, discusses technical details such as Data URIs, mapping, redirects, and provides concrete examples including Flickr API URL patterns.
URL design is a very important but often overlooked part, and few architects pay attention to it. In a system architecture, a good URL design can have a positive impact on the whole system.
URI, URL and URN
URL is the most familiar term, while URI and URN are less known. URI, URL and URN are standard ways to identify, locate and name resources on the Internet. Tim Berners‑Lee invented the World Wide Web in 1989, which is considered a collection of actual and abstract resources that can be accessed via the Internet.
Because resources need to be identified in many ways (people may have the same name, but a computer file must have a unique path), a standard identification method is required. Tim Berners‑Lee introduced URI, URL and URN to satisfy this need.
URI: Uniform Resource Identifier
URL: Uniform Resource Locator
URN: Uniform Resource Name
In this hierarchy, URI is at the top level, while URL and URN are sub‑categories of URI.
URI can be viewed as a locator (URL), a name (URN), or both. A URN is like a person's name, while a URL is like an address. In other words, a URN defines the identity of something, and a URL provides a way to locate it.
ISBN is a typical URN example. ISBN 0‑486‑27557‑4 uniquely identifies a specific edition of Shakespeare’s "Romeo and Juliet". To read the book, you need its location – a URL such as file:///home/username/RomeoAndJuliet.pdf . Thus URN and URL complement each other.
URL
A URL is a string used on the Internet to describe an information resource. It provides a uniform format for describing files, server addresses, directories, etc.
The format consists of three parts:
Protocol (or service method)
Host IP address (sometimes with port)
Specific resource path, such as directory and file name
The first and second parts are separated by "://", the second and third parts by "/". The first two parts are mandatory; the third part can be omitted.
The biggest drawback is that when the location of a resource changes, the URL must be updated, which is why new representation methods are being researched.
URN
URN (Uniform Resource Name) is a standard‑format URI that identifies a resource without specifying its location or existence. Example from RFC 3986: urn:oasis:names:specification:docbook:dtd:xml:4.1.2
Key differences between URN and URL:
URN provides persistent identification of a resource.
URL mainly provides a path; the path may change over time, and a URL does not guarantee uniqueness or permanence.
URN is designed to interoperate with existing identifier systems such as ISSN. Its structure follows the URI syntax:
URN Structure
URN:NID:NSS
Thus a URN contains at least three parts:
URN scheme (e.g., urn )
NID – a namespace identifier registered with IANA
NSS – namespace‑specific string that uniquely identifies the resource
ISSN and URN
ISSN was the first book identifier to adopt the URN scheme. An ISSN can be expressed as:
URN:ISSN:xxxx-xxxx
urn:issn:xxxx-xxxx
UrN:IsSn:xxxx-xxxx
For example, urn:issn:1234-1231 . It is recommended to record the URN in the metadata of a web resource, e.g. in the HTML <head> :
META NAME="Identifier" SCHEME="URN:ISSN" CONTENT="1234-1231"
URI
A URI is a simple string that uniquely identifies a resource using a standardized format. It generally consists of three parts:
Naming mechanism for accessing the resource
Host name where the resource resides
Resource name expressed as a path
URI is the superset; URL is a subset of URI.
Typical syntax starts with a scheme, e.g.:
scheme://authority/path?query#fragment
Some URIs end with a fragment identifier ("#") that points to an internal part of the resource.
Relative URIs contain no naming information and usually refer to resources on the same server.
Common URI Problems
Hard to type, unnecessarily long
Confusing case sensitivity
Uncommon punctuation
Difficult to display on paper
Host and port confusion
Immature Technology: Data URI
Data URI, defined by RFC 2397, embeds small files directly into a document. Syntax:
data:[<MIME-type>][;base64],<data>
Advantages :
Reduces HTTP requests and TCP overhead.
For small files, can lower bandwidth when header size exceeds the encoding overhead.
Avoids mixed‑content warnings on HTTPS sites.
Allows the whole page to be saved as a single file.
Disadvantages :
Cannot be reused; duplication increases size.
Not cacheable; must be re‑downloaded with the page.
Client must decode; base64 adds ~33% size.
May bypass security filters and pose risks.
Tools such as "Data URI Generator" can convert files to this format.
Good URIs Should Not Change
A stable URI is crucial because users may bookmark, share, or reference it elsewhere. Changing a URI can break trust and cause frustration.
Website redesign
Removal of outdated or confidential documents
File relocation
Switch from CGI script to binary program
Belief that only URN needs permanence
How to Design a Stable URI
Design URIs that can survive for years. Keep creation date immutable, separate mutable metadata (status, permissions) from the URI, and avoid embedding volatile information such as author names or titles.
Example of a stable URI:
http://www.example.com/money/moneydaily/
When a date is needed, use a separate archival URI:
http://www.example.com/money/moneydaily/1998/981212.moneyonline.html
URL as UI
Easy‑to‑remember and spellable domain name
Short URL
Easy to type
Visual hierarchy
Users can trim the last segment to go up a level
URL should remain unchanged
Users often rely on impressions rather than exact URLs, so a memorable domain and short path are important.
How to Design a Good URL
Simple, memorable domain
Short URL
Easy to input
Reflects site structure
Predictable and hackable (encouraged)
Permanent link
Remember four rules:
User‑friendly
Readable
Predictable
Consistent
Root Section Is Precious
The root section of a URL determines the overall organization of the site. Decide early which root sections must be preserved.
Namespaces Are Useful Extensions
Example: https://github.com/pallets/flask/issues – "pallets/flask" is a namespace. Anything after the namespace becomes a level section.
Query Strings for Sorting and Filtering
Many sites use query strings like ?sort=alpha&dir=desc to simplify sorting and filtering.
Non‑ASCII Characters in URLs
Non‑ASCII characters are hard to type and remember. URLs should be designed for humans, not search engines.
Use hyphens, not underscores.
Prefer short, common words.
URL as a Contract
A URL is an agreement: once published, it should remain stable. If a change is unavoidable, use proper redirects (301, 302, 307).
Mapping and Redirection Techniques
Aliases (Apache), virtual directories (IIS)
Symbolic links (Unix)
Database tables mapping logical URIs to physical files
Standard Redirection
301 Moved Permanently
302 Found
307 Temporary Redirect
Technology‑Independent URIs
Do not expose script language or platform in the URI (avoid cgi-bin , servlet ).
Hide file extensions for static content using content negotiation or proxies.
Identity and Session
Use standard authentication mechanisms instead of per‑user URIs.
Store session IDs outside the URI.
Standard Redirection on Content Change
Use HTTP redirects for moved content.
Return HTTP 410 for deleted resources.
Indexing Proxies
Content‑Location header
Content‑MD5 header
Provide Proper Cache Information
Cache‑related HTTP headers
Cache policies
Cache generation via HEAD and GET
Summary
URI is part of the web UI and should be treated like a logo or brand.
URI is the sole interface between a website and ordinary users; treat it with the same care as a business phone number.
URL Fragment (Hash) Usage
The hash specifies a position within the page; it is not sent to the server.
Changing the hash does not reload the page but creates a history entry.
JavaScript can modify location.hash ; the onhashchange event fires on change.
Googlebot ignores the hash unless the URL uses "#!", in which case it requests ?_escaped_fragment_=... .
Flickr API URL Rules Example
Flickr image URLs have three main patterns:
http://farm{farm-id}.static.flickr.com/{server-id}/{id}_{secret}.jpg
http://farm{farm-id}.static.flickr.com/{server-id}/{id}_{secret}_[mstzb].jpg
http://farm{farm-id}.static.flickr.com/{server-id}/{id}_{o-secret}_o.(jpg|gif|png)
Size suffixes:
s
small square, 75×75
t
thumbnail, longest side ≤100
m
small, longest side ≤240
-
medium, longest side ≤500
z
medium 640, longest side ≤640
b
large, longest side ≤1024
o
original image (jpg, png, gif)
Example URL: http://farm1.static.flickr.com/2/1418878_1e92283336_m.jpg
farm-id: 1
server-id: 2
photo-id: 1418878
secret: 1e92283336
size: m
Flickr also provides short URLs using Base58 encoding: http://flic.kr/p/{base58-photo-id} .
Additional Resources
For further reading, the article lists many related links (e.g., open‑source admin panels, IM systems, interview questions, Redis use cases, Elasticsearch, etc.).
Top Architect
Top Architect focuses on sharing practical architecture knowledge, covering enterprise, system, website, large‑scale distributed, and high‑availability architectures, plus architecture adjustments using internet technologies. We welcome idea‑driven, sharing‑oriented architects to exchange and learn together.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.