3.1. Semantica generica

3.1. Semantica generica

Gran parte del valore di HTTP risiede nella sua semantica generica -- cioè, gli elementi di protocollo definiti da HTTP sono potenzialmente applicabili a ogni risorsa e non sono specifici per un contesto particolare. Le semantiche specifiche dell'applicazione sono meglio espresse nel contenuto dei messaggi e nei campi di intestazione, non nei codici di stato o nei metodi (sebbene i codici di stato e i metodi abbiano una semantica generica che si riferisce allo stato dell'applicazione).

Questa separazione tra semantica generica e specifica dell'applicazione consente che un messaggio HTTP sia gestito da software comune (ad esempio, server HTTP, intermediari, implementazioni client e cache) senza richiedere che tali implementazioni comprendano l'applicazione in uso. Consente anche alle persone di sfruttare la loro conoscenza della semantica HTTP senza aver bisogno di conoscenze specializzate di una particolare applicazione.

Pertanto, le applicazioni che utilizzano HTTP NON DEVONO ridefinire, affinare o sovrapporre la semantica di elementi di protocollo generici come metodi, codici di stato o campi di intestazione esistenti. Invece, dovrebbero concentrare le loro specifiche sugli elementi di protocollo che sono specifici per la loro applicazione -- vale a dire, le loro risorse HTTP.

Vedere [BCP190] per ulteriori informazioni.

Quando si scrive una specifica, è spesso tentante specificare esattamente come HTTP deve essere implementato, supportato e utilizzato. Tuttavia, questo può facilmente portare a un profilo involontario del comportamento di HTTP. Ad esempio, è comune vedere specifiche con linguaggio come questo:

Una richiesta POST DEVE risultare in una risposta 201 Created.

Questo crea un'aspettativa nel client che la risposta sarà sempre 201 Created quando, in realtà, quella risposta non è affatto certa. È attesa solo quando il server crede che una nuova risorsa sia stata creata, ma vari motivi (come una politica di sicurezza) potrebbero impedire al server di creare una nuova risorsa o confermare che la risorsa è stata creata.

Un linguaggio più appropriato sarebbe:

Una richiesta POST riuscita DOVREBBE risultare in una risposta 201 Created quando una risorsa è stata creata.

Una specifica può utilizzare istanze specifiche di elementi di protocollo per segnalare semantica specifica dell'applicazione. In un certo senso, è così che la semantica generica viene specializzata per l'applicazione. Ad esempio, un'applicazione potrebbe definire una richiesta POST con un Content-Type specifico per significare "crea una nuova risorsa con la rappresentazione allegata". Poiché la semantica è specifica dell'applicazione, deve essere definita nella specifica dell'applicazione.

Vedere la Sezione 4.7 per i dettagli sui campi di intestazione definiti dall'applicazione.