Le world-wide web, en anglais : toile d'araignée mondiale, arrive et se développe dans un contexte particulièrement déterminant :

Le web, par ailleurs, est un système orienté document à l'usage direct des utilisateurs. Sa facilité de désignation des diverses ressources en a fait l'outil par excellence de l'intégration sous un même type d'interfaces de très nombreux services.

Cette volonté intégratrice est illustrée par les adresses Internet telles qu'utilisées par le web : les URI, en anglais Uniform Resource Identifier, les Identifiants Uniformes de Ressources, sous-entendu « sur Internet » [RFC2396, RFC1738]. Pour les types de ressources les plus populaires (pages web, transfert de fichiers, courrier électronique) on parle d'URL, en anglais Uniform Resource Locator, soit Localisateur Uniforme de Ressources (URL a un sens officiel plus technique [cf. RFC2396, § 1.2]).

Ces URI (dont les URL) forment un système extrêmement ouvert : chaque type de ressources peut disposer de son schéma d'URI [URI scheme]. Ainsi, on a même proposé un schéma d'URI pour les accès téléphoniques (RFC n° 2806). D'autres schémas sont plus spécifiques à un système donné, comme des URI de manuels Unix, p.ex.: man:/sh(1). Parmi tous ces schémas, tous ne sont pas officiels. L'IANA diffuse la liste officielle des schémas d'URI [IANA-URI].

L'objectif, largement réalisé pour les services usuels, est que le même logiciel ou ensemble de logiciels soit à même de donner accès à toutes ces ressources, c'est à dire comprenne un logiciel client des protocoles correspondants. Quand ce n'est pas le cas, les navigateurs font appel à des logiciels externes (par exemple pour les connexions par terminaux).

Les URI, même si elles suivent des principes différents, respectent néanmoins quelques règles très générales (donc susceptibles d'exceptions).

Dans tous les cas, les URI ont la même allure :

nom-du-schéma-ou-du-protocole:partie-spécifique

où le schéma d'URI est généralement (mais pas toujours) l'acronyme du protocole sur lequel repose le service. Exemple : HTTP pour le web, FTP pour le transfert de fichier, RTSP pour la diffusion en temps-réel etc.

Seconde règle, les URI ne sont formées que d'un nombre limités de caractères admis, en général : les lettres et chiffres (a à z, A à Z, 0 à 9), le point (.), le tiret (-), l'oblique (/, à ne pas confondre avec l'oblique "de" Microsoft : \). Les autres caractères doivent être remplacés par des codes : l'espace est codé par un plus (+) et les autres signes par un symbole pourcent (%) suivi du code hexadécimal à deux chiffres du signe remplacé (p.ex.: é se code %E9 dans l'encodage Latin-1 et %C3%A9 dans l'encodage Unicode UTF-8).

La casse (différence majuscule/minuscule) peut compter, contrairement à ce qui est en usage sous Windows ou MacOS. Ainsi fromage.html et Fromage.HTML peuvent désigner des fichiers différents.

Dans le cas d'un protocole impliquant un service directement assuré sur Internet par un ordinateur spécifique appelé hôte (web, transfert de fichiers, terminal, p.ex.), l'URL peut fréquemment prendre l'allure générale suivante :

schéma://compte:mot-de-passe@hôte:port/chemin

Dans ce schéma général, certaines parties sont généralement absente quand il n'est pas nécessaire, possible ou souhaitable de les exprimer. Ainsi, compte:mot-de-passe@, qui sert à identifier l'utilisateur, est absente quand elle n'est pas utile. Quand l'utilisateur est présent, :mot-de-passe peut être absent quand le code d'accès doit être demandé à l'utilisateur, par exemple. De même, l'indication :port n'est utile que quand le service n'utilise pas son port standard. Enfin, /chemin, qui sert à indiquer une localisation de ressource sur un serveur donné, est également facultatif. On trouvera ainsi les URL suivantes :

ftp://untel@fichier.exemple.org/documents
telnet://demo:demo@test.banque-en-ligne.fr
http://www.exemple.org:8080/test/page-de-garde.html

Note : Ce schéma ne permet pas d'utiliser les caractères @, : et / (ni d'autre caractère spécial) dans des noms de comptes ni mots de passe. Si le cas se présente, il faut les coder (une liste des codes -presque- indépendants de l'encodage est fournie en appendice) :

Nous n'évoquerons ici que les services destinés aux utilisateurs humains, pas les services "cachés", tels que le DNS, évoqué plus haut.