Dialogare con servizi web che espongono dati in lettura e/o scrittura è diventata la norma. Molto spesso questi servizi si basano sulla ben nota architettura REST con tutti i vantaggi e gli svantaggi del caso. La questione su cui vorrei concentrarmi è il formato per l’interscambio delle informazioni. L’architettura REST non impone nessun vincolo in merito e con il tempo si sono consolidati 2 formati principali: XML e JSON. XML lo conosciamo bene da anni è l’arcinoto markup language pensato e concepito proprio per l’interscambio di dati e assai diffuso fin dalla sua nascita nel lontano 1998. JSON invece, nonostante sia relativamente giovane (parliamo del 2001/2002 anche se l’RFC è del 2006), ha preso piede dopo che Yahoo prima e Google poi lo hanno utilizzato nei propri servizi web e protocolli. Ora è diventato un formato che va molto di moda soprattutto sul web.
Senza fare una sterile guerra di religione tra i due formati voglio esprimere la mia personale e relativa preferenza per JSON. JSON è un formato per serializzare semplice e decisamente più leggero in termini di dimensione e di elaborazione computazionale. XML al contrario presenta una forma più complessa per la rappresentazione dell’informazione a scapito, chiaramente, delle prestazioni e delle dimensioni. Con questo non voglio dire l’XML non sia la scelta giusta da fare, anzi. Proprio l’espressività di XML può essere necessaria quando l’informazione d’interscambio è complessa e strutturata. JSON d’altro canto è fin troppo semplice e richiede del lavoro aggiuntivo quando si deve poter gestire dati particolarmente complicati e fortemente tipizzati.
La mia scelta per JSON ricade in un ambito ben preciso e delineato: lo sviluppo mobile. I miei primi progetti mobile con iOS utilizzavano pesantemente XML come formato d’interscambio con la parte server del sistema. Come conseguenza di questa scelta vi era un utilizzo, talvolta eccessivo, della classe NSXMLParse fornita dall’SDK. Utilizzare NSXMLParse può essere un vero delirio e quando il fattore tempo è determinante una scelta tecnologica sbagliata può essere fatale.
Negli ultimi due progetti ho deciso di utilizzare pesantemente JSON per la comunicazione tra client e server . In particolare mi sono avvalso del framework opensource SBJson per tutta l’attivita di parsing. Sono rimasto piacevolmente colpito dalla semplicità e dalla potenzialità del framework, ma soprattutto dalla sua velocità. Su un dispositivo con risorse limitate, come l’iphone, è importante ridurre al minimo il consumo dei vari componenti. In questo caso JSON ci viene incontro con la sua semplicità e un parser come SBJson può fare la differenza rispetto al blasonato NSXMLParser e XML.
SBJson non è l’unico framework per iPhone e iPad. Esistono almeno altri 3 framework interessanti e sono JSONKit, TouchJSON e YAJL. Ognuno con le proprie caratteristiche, ognuno con un set di funzionalità apprezzabili. Si ma quale scegliere? Un metro di valutazione potrebbe essere la velocità, fattore importante su un device che fa della rapidità un suo cavallo di battaglia. Per aiutarci nella scelta su GitHub è possibile scaricare il JSON Benchmarks che permette di effettuare dei benchmarks appunto sui i 4 framework citati. Ho fatto alcune prove con il mio iPhone 4 (con iOS 4.3.4) e questi sono i risultati a fronte di 100 iterazioni:
A mio avviso SBJson offre un buon compromesso tra prestazioni e funzionalità e in definitiva è la mia scelta. E poi è semplice da usare. E’ sufficiente passare al parser una variabile NSData (o una NSString) con all’interno i dati in json e lui ti ritorna un NSDictionary o un NSArray a seconda del formato. Niente a confronto della complessità associata ad un NSXMLParser.
Non escludo però di valutare nell’immediato futuro anche il JSONKit che promette prestazioni da urlo.
