API for (epub) ebooks. Un prototipo

TL;DR: Ho sviluppato e messo opensource un prototipo di implementazione di API RESTful dedicate a EPUB(2). Il progetto si chiama py-clave, e permette di restituire comodamente in JSON informazioni bibliografiche, indice dei contenuti, capitoli e frammenti specifici tratti da un set di file EPUB. Il progetto è su github, la documentazione delle chiamate – spero esaustiva – è su Apiary, la home page del progetto è temporaneamente ospitata su dev.alese.it.

No, really: TL!? Vuoi qualcosa da cliccare? Questo è il catalogo delle pubblicazioni presenti sul server, queste sono le informazioni bibliografiche di una pubblicazione, questa la TOC della pubblicazione di prima, questo è un capitolo specifico della pubblicazione, questo è un “frammento” – un paragrafo – del capitolo di prima. Oppure, puoi semplicemente scaricare tutto l’EPUB.

What’s in an API?

Qualche tempo fa si è fatto un gran parlare attorno alla trasformazione della funzione editoriale, inquadrandola nell’occhio del ciclone del processo di disruption in cui è stata coinvolta dall’irruzione dei paradigmi (tecnologie, servizi, interfacce) del digitale. Molto correttamente, Baldur Bjarnason ha criticato il paradigma stagnante dell’editoria elettronica rimarcando come il potenziale innovativo del libro elettronico sia stato «dirottato» in modo da mantenere «l’ordine costituito» delle cose, cioè – aggiungo io – la stessa value chain dell’editoria “concreta” e lo stesso modello di product delivery, in evidente contraddizione con il paradigma imposto dal web, che è un protocollo che costituisce un ecosistema dove i contenuti vengono prodotti, scambiati, consumati da umani e da macchine.

Anch’io ho parlato di qualcosa del genere nel mio tradizionale post di fine anno, Alcune cose che abbiamo imparato nel 2012 a proposito di editoria (digitale), e altre che ancora dobbiamo imparare, tirando un po’ le fila dello stantìo bla-bla-bla italiano sulle cose che si potrebbero fare in editoria digitale e chiedendomi, come ha fatto anche Rachieli nel succitato post su Apogeonline, perché non abbiamo neanche cominciato a sfruttare una piccola parte di quello che lo stato dell’arte della tecnologia ci offre.

Dicevo, infatti:

La parola d’ordine del 2013 sarà API: chi pensava che il commercio elettronico si potesse risolvere con dei file su un hosting ha già avuto una brutta sorpresa quest’anno; nel 2013 si farà sul serio, e la selezione naturale sarà durissima tra i professionisti che non conoscono a menadito il paradigma REST o che non sappiano effettuare delle RPC.

Cosa è stato fatto?

Di API si è parlato in lungo e in largo, talmente tanto che non è pensabile reperire un numero di link sufficiente a offrire una panoramica dello stato del dibattito; molto spesso se ne è parlato senza una completa cognizione di causa, confondendo API e webapp, quando non addirittura confondendo API e social network (chiediamoci di nuovo perché l’evoluzione dell’editoria digitale è al palo).

Altrove si sono prodotti invece degli esperimenti interessanti. Hugh McGuire, la mente dietro Pressbooks, ha presentato la sua idea di “Books as API” al DigitalBook 2013 tenutosi durante la BookExpo of America. Se non avete provato PressBooks, vi consiglio di farlo: è l’incarnazione del proposito di portare uno step oltre il livello di consumabilità delle pubblicazioni elettroniche sul web.

Un colosso editoriale come HarperCollins ha sviluppato in collaborazione con Mashery le sue OpenBook API, pensate per offrire in lettura le informazioni editoriali del proprio catalogo e dei contenuti scelti dalle proprie pubblicazioni. Un’iniziativa che ha riscosso un buon successo, almeno a giudicare dal gran parlare che si è fatto del loro contest per sviluppatori, BookSmash Challenge.

Mi chiedo perché una multinazionale potente come HC abbia sentito il bisogno di rivolgersi in questo modo alla comunità di sviluppatori. Se da una parte è comprensibile che una casa editrice non sia sufficientemente addentra alle dinamiche di comunità dello sviluppo di software, è anche possibile che il pur modesto investimento compiuto per sviluppare questa API si sia successivamente scontrata con il proverbiale e adesso?

Quello che ho cercato di capire, da operatore del settore (coff), è stato:

  • A quale bisogno risponde un’API?
  • A che pubblico si rivolge?
  • In che modo il suo sviluppo è funzionale in ottica B2B?
  • … e in che modo i consumatori possono beneficiarne?
  • Peraltro: un editore cosa ci guadagna?

Domande piuttosto urgenti, tanto più che abbiamo abbondantemente superato il giro di boa di metà 2013, senza che nemmeno una delle problematiche emerse nel 2012 si sia chiaramente avviata verso una soluzione.

Ma ancora più urgente diventa tracciare una linea tra il parlare che si fa a proposito di idee e progetti tratteggiati nell’aria e provare a mettere, metaforicamente, nero su bianco delle idee diffuse. Mi sono guardato attorno, ho seguito un po’ di persone che si occupano quotidianamente di queste faccende, e mi sono convinto a fare un passo avanti e provare a proporre qualcosa che fosse utile come base di discussione e che, marginalmente, potesse anche funzionare come demo di un’idea e un approccio di funzionalità. Nel solco dell’illustre tradizione, allora, quando non trovi in giro quello che ti serve, fattelo da solo.

La mia idea

Questo è il razionale dietro py-clave, l’implementazione che ho sviluppato di una API per ebook, scritta in Python e basata sul framework Tornado (quello di FriendFeed, per intenderci) per gestire un server HTTP asincrono, non-blocking, velocemente deployabile e altamente scalabile che restituisce informazioni inerenti a un insieme di pubblicazioni EPUB.

La API di py-clave presenta un’interfaccia, tecnicamente intesa, pensata per offrire a un client (accessibile programmaticamente in curl o tramite chiamate AJAX) l’accesso a metadati, indice dei contenuti, capitoli o frammenti di pubblicazioni, secondo la logica RESTful. Per i dettagli vi rimando alla documentazione, che è più completa, esaustiva e soprattutto viene aggiornata.

Tutto il codice è open source, accompagnato dalla licenza MIT, iperliberale: permette a chiunque di fare qualsiasi cosa del codice, estenderlo, modificarlo, usarlo e rivenderlo (lol, buona fortuna). Sarei molto contento di ricevere, qui o su github, richieste di fork, commenti, segnalazioni di bug e in generale consigli e indicazioni. Mi piacerebbe che py-clave costituisse il wireframe di un progetto più ampio e funzionale, che aiutasse gli sviluppatori a dispiegare le proprie capacità e fantasie, aiutando la comunità degli e-producer a non fossilizzarsi a ritenere l’ebook un prodotto fatto e finito, concepito per funzionare in un sistema chiuso e riportasse l’attenzione di tutti sul luogo migliore per coltivare l’intelletto e i suoi prodotti: l’open web, quella infrastruttura costituita di protocolli concordati, standard e interoperabili. Quella cosa che lo strapotere di poche multinazionali sta facendo dimenticare, dondolando di fronte al naso di sviluppatori e consumatori il comfort e la sicurezza di un walled garden.

Contribuire

Ogni contributo, e intendo dire qualsiasi contributo è caldamente benvenuto. Siate anche impietosi col mio codice (quando vorrò impietosirvi verrò a ricordarvi in cosa sono laureato, sono certo che sarete assai più indulgenti) e severi nel sottolineare cosa non funziona, cosa non fa ma dovrebbe fare e cosa fa ma non dovrebbe fare. Potrei essere capace di implementarlo da me, oppure – nel caso probabile in cui non ne fossi in grado – potresti farlo tu. Oppure, puoi semplicemente scaricare la prima release alpha da github e provare. Poi dimmi come ti trovi, qui nei commenti, per mail, o su Twitter.

 

Gabriele

 

4 thoughts on “API for (epub) ebooks. Un prototipo

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>