2. Migliori pratiche attuali per la standardizzazione di URI strutturati (Best Current Practices for Standardizing Structured URIs)

Questa sezione aggiorna [RFC3986] consigliando come le specifiche dovrebbero definire struttura e semantica all'interno degli URI. Le migliori pratiche differiscono a seconda del componente URI in questione, come descritto di seguito.

2.1. Schemi URI (URI Schemes)

Le applicazioni e le estensioni possono (MAY) richiedere l'uso di uno o più schemi URI specifici; ad esempio, è perfettamente accettabile richiedere che un'applicazione supporti URI "http" e "https". Tuttavia, le applicazioni non dovrebbero (ought not) precludere l'uso di altri schemi URI in futuro, a meno che non siano chiaramente utilizzabili solo con gli schemi nominati.

Una specifica che definisce una sotto-struttura per gli schemi URI nel complesso (ad esempio, un prefisso o suffisso per i nomi degli schemi URI) deve (MUST) farlo modificando [BCP35] (una circostanza eccezionale).

2.2. Autorità URI (URI Authorities)

Le definizioni degli schemi definiscono la presenza, il formato e la semantica di un componente autorità negli URI; tutte le altre specifiche non devono (MUST NOT) vincolare o definire la struttura o la semantica per le autorità URI, a meno che non aggiornino la registrazione dello schema stesso o le strutture su cui si basa (ad esempio, la sintassi dei nomi DNS, come definito nella sezione 3.5 di [RFC1034]).

Ad esempio, un'estensione o un'applicazione non può dire che il prefisso "foo" in "https://foo_app.example.com" è significativo o attiva una gestione speciale negli URI, a meno che non aggiornino lo schema URI "http" o la sintassi del hostname DNS.

Le applicazioni possono (MAY) nominare o vincolare la porta che utilizzano, quando applicabile. Ad esempio, BarApp potrebbe funzionare sulla porta nnnn (a condizione che sia adeguatamente registrata).

2.3. Percorsi URI (URI Paths)

Le definizioni degli schemi definiscono la presenza, il formato e la semantica di un componente percorso negli URI, sebbene questi siano spesso delegati alle applicazioni in una determinata distribuzione.

Per evitare collisioni, rigidità e ipotesi errate del client, le specifiche non devono (MUST NOT) definire un prefisso fisso per i loro percorsi URI -- ad esempio, "/myapp" -- a meno che non sia consentito dalla definizione dello schema.

Un'eccezione a questo requisito sono gli URI "ben noti (well-known)" registrati, come specificato da [RFC8615]. Consultare tale documento per una descrizione dell'applicabilità di tale meccanismo.

Si noti che questo non si applica alle applicazioni che definiscono una struttura del percorso di un URI "sotto" una risorsa controllata dal server. Poiché il prefisso è sotto il controllo della parte che distribuisce l'applicazione, le collisioni e la rigidità vengono evitate e il rischio di ipotesi errate del client viene ridotto.

Ad esempio, un'applicazione potrebbe definire "app_root" come un prefisso URI controllato dalla distribuzione. Le risorse definite dall'applicazione potrebbero quindi essere supposte presenti in "{app_root}/foo" e "{app_root}/bar".

Le estensioni non devono (MUST NOT) definire una struttura all'interno dei singoli componenti URI (ad esempio, un prefisso o suffisso), ancora una volta per evitare collisioni e ipotesi errate del client.

2.4. Query URI (URI Queries)

La presenza, il formato e la semantica del componente query degli URI dipendono da molti fattori e possono essere vincolati da una definizione di schema. Spesso, sono determinati dall'implementazione di una risorsa stessa.

Le applicazioni possono (MAY) specificare la sintassi delle query per le risorse sotto il loro controllo. Tuttavia, farlo può causare difficoltà operative per le distribuzioni che non supportano una particolare forma di query. Ad esempio, un sito potrebbe desiderare di supportare un'applicazione utilizzando file "statici" che non supportano parametri di query.

Le estensioni non devono (MUST NOT) vincolare il formato o la semantica delle query, per evitare collisioni e ipotesi errate del client. Ad esempio, un'estensione che indica che tutti i parametri di query con il nome "sig" indicano una firma crittografica entrerebbe in collisione con parametri di query potenzialmente preesistenti sui siti e porterebbe i client a presumere che qualsiasi parametro di query corrispondente sia una firma.

Secondo la sezione "Invio di moduli (Form submission)" di [HTML5], HTML vincola la sintassi delle stringhe di query utilizzate nell'invio di moduli. I nuovi linguaggi di moduli sono incoraggiati a consentire la creazione di una più ampia varietà di URI (ad esempio, consentendo al modulo di creare nuovi componenti di percorso, ecc.).

2.5. Identificatori di frammento URI (URI Fragment Identifiers)

La sezione 3.5 di [RFC3986] specifica che la sintassi e la semantica degli identificatori di frammento dipendono dal tipo di media di una risorsa potenzialmente recuperata. Di conseguenza, le altre specifiche non devono (MUST NOT) definire una struttura all'interno dell'identificatore di frammento, a meno che non ne definiscano esplicitamente una per il riutilizzo da parte dei tipi di media nelle loro definizioni (ad esempio, come fa JSON Pointer [RFC6901]).

Un'applicazione che definisce identificatori di frammento comuni su tipi di media non controllati da essa genererebbe problemi di interoperabilità con i gestori di tali tipi di media (perché la nuova sintassi non standard non è prevista).