Appendix A. Frequently Asked Questions (Domande frequenti)
A.1 Why Not JSON? (Perché non JSON?)
Le prime proposte di campi strutturati erano basate su JSON [RFC8259]. Tuttavia, vincolare il suo uso per adattarlo ai campi di intestazione HTTP richiedeva che mittenti e destinatari implementassero un'elaborazione aggiuntiva specifica.
Problemi con JSON
1. Problemi di canonizzazione
- Grandi numeri (superano l'intervallo sicuro di JavaScript)
- Oggetti con membri duplicati (comportamento non definito)
2. Stringhe Unicode
- Potenziali problemi di interoperabilità nei confronti
- Diverse rappresentazioni Unicode per lo stesso carattere
3. Profondità di nidificazione arbitraria
- Impegni di memoria inappropriati
- Necessità di limitarlo in qualche modo
- Le implementazioni JSON esistenti non hanno tali limiti
4. Tentazione dell'implementazione
- Difficile imporre vincoli aggiuntivi
- Le persone tendono a utilizzare parser JSON sui valori dei campi
Conclusione
Queste preoccupazioni hanno portato all'adozione di un formato che richiede parser e serializzatori dedicati, poiché l'obiettivo principale era migliorare l'interoperabilità e semplificare l'implementazione.
Tabella comparativa
| Caratteristica | JSON | RFC 8941 |
|---|---|---|
| Intervallo numerico | Indefinito | Chiaramente definito (15 cifre) |
| Precisione decimale | Indefinita | 3 cifre |
| Unicode | Predefinito | Solo ASCII |
| Profondità | Illimitata | Limitata a 2 livelli |
| Chiavi duplicate | Non definito | Esplicitamente vietato |
| Adattamento HTTP | Scarso | Eccellente |
Esempio pratico
Approccio JSON (problematico)
Example-Header: {"priority": 1, "timeout": 3.14159, "enabled": true}
Approccio RFC 8941 (raccomandato)
Example-Header: priority=1, timeout=3.142, enabled
Vantaggi: Definizione di tipo chiara, comportamento prevedibile, si adatta naturalmente a HTTP.