1. Introduzione

1. Introduzione

Le applicazioni diverse dalla navigazione Web spesso utilizzano HTTP [HTTP] come substrato, una pratica talvolta definita creazione di "API basate su HTTP", "API REST" o semplicemente "API HTTP". Questo viene fatto per una varietà di ragioni, tra cui:

• familiarità da parte di implementatori, specificatori, amministratori, sviluppatori e utenti;

• disponibilità di una varietà di implementazioni di client, server e proxy;

• facilità d'uso;

• disponibilità di browser Web;

• riutilizzo di meccanismi esistenti come autenticazione e crittografia;

• presenza di server e client HTTP nelle distribuzioni target; e

• la sua capacità di attraversare i firewall.

Questi protocolli sono spesso ad hoc, destinati solo alla distribuzione da parte di uno o pochi server e al consumo da parte di un insieme limitato di client. Di conseguenza, è emerso un corpus di pratiche e strumenti per definire API basate su HTTP che favoriscono queste condizioni.

Tuttavia, quando tale applicazione ha più implementazioni separate, viene distribuita su più server non coordinati e viene consumata da client diversi (come spesso accade per le API HTTP definite da sforzi di standardizzazione), gli strumenti e le pratiche destinati a una distribuzione limitata possono diventare inadatti.

Questa discrepanza è in gran parte dovuta al fatto che i client e i server dell'API implementeranno ed evolveranno a ritmi diversi, portando alla necessità che le distribuzioni con diverse funzionalità e versioni coesistano. Di conseguenza, i progettisti di API basate su HTTP destinate a tali distribuzioni devono considerare più attentamente come sarà gestita l'estensibilità del servizio e come saranno soddisfatti i diversi requisiti di distribuzione.

Più in generale, un protocollo di applicazione che utilizza HTTP si trova di fronte a una serie di decisioni di progettazione, tra cui:

• Dovrebbe definire un nuovo schema URI? Utilizzare nuove porte?

• Dovrebbe utilizzare metodi e codici di stato HTTP standard o definirne di nuovi?

• Come può essere estratto il massimo valore dall'uso di HTTP?

• Come coesiste con altri usi di HTTP -- in particolare la navigazione Web?

• Come possono essere evitati problemi di interoperabilità e "vicoli ciechi del protocollo"?

La sezione 2 definisce quando questo documento si applica, la sezione 3 esamina le proprietà di HTTP che sono importanti da preservare, e la sezione 4 contiene le migliori pratiche per la specifica di applicazioni che utilizzano HTTP.

È scritto principalmente per guidare gli sforzi IETF per definire protocolli di applicazione utilizzando HTTP per la distribuzione su Internet, ma potrebbe essere applicabile in altre situazioni. Si noti che i requisiti qui contenuti non si applicano necessariamente allo sviluppo di estensioni HTTP generiche.

Questo documento rende obsoleto [RFC3205] per riflettere l'esperienza e gli sviluppi riguardanti HTTP nel frattempo.