"Le API pubbliche sono per sempre: una sola possibilità per farlo bene"?

In un libro sul sistema operativo ho appena letto che "Le API pubbliche sono per sempre: solo una possibilità per farlo bene". È vero? È applicabile solo nelle API dei sistemi operativi o anche in altre API? Ad esempio, questo sarà vero per le API di applicazioni Android come Tasker, Locale e Pushover?

È generalmente vero per qualsiasi API pubblica, sì. Una volta esposta un'API al pubblico e le persone iniziano a creare applicazioni che dipendono da quell'API, diventa estremamente difficile modificare l'API perché così facendo si romperanno tutte quelle applicazioni. Questo tende ad essere sia un problema tecnico difficile che un problema politico difficile.

Naturalmente, è possibile modificare un'API pubblica. Accade, ad esempio, che i progetti privino un'API in una versione, introducano una nuova API e quindi rimuovano la vecchia API in una versione futura. Ma ciò presuppone che ogni (importante) applicazione che utilizza la vecchia API verrà riscritta per utilizzare la nuova API prima di rimuovere la vecchia API. Ciò richiede spesso più anni. Ciò significa che il proprietario dell'API pubblica sta imponendo un costo su ogni altro progetto che consuma l'API. Dato che in genere ci sono molti più consumatori di un'API, quei consumatori tendono ad essere una lobby politica relativamente potente.

L'autore della citazione è Joshua Bloch, l'affermazione è tratta dal suo articolo di progettazione dell'API Bumper-Sticker :

Le API pubbliche, come i diamanti, sono per sempre. Hai una possibilità per farlo bene, quindi fai del tuo meglio.

Per maggiori dettagli, l'autore rimanda i lettori alla presentazione della sessione della conferenza, "Come progettare una buona API e perché è importante" . Diapositiva Perché la progettazione API è importante per te afferma chiaramente che ciò è rilevante per qualsiasi attività di programmazione (sistemi operativi o meno, non importa per l'autore):

• Se programmi, sei un designer API

  • Il buon codice è modulare: ogni modulo ha un'API

• I moduli utili tendono a essere riutilizzati

  • Una volta che il modulo ha utenti, non è possibile modificare l'API a piacimento
  • I buoni moduli riutilizzabili sono beni aziendali

• Pensare in termini di API migliora la qualità del codice

Slide Conclusion sottolinea anche questo come approccio generale:

• Il design delle API è un mestiere nobile e gratificante

  • Migliora il numero di programmatori, utenti finali, aziende ...

Le API cambiano sempre, altrimenti quale sarebbe il punto di aggiornamento del sistema? Cambiare solo internals?

Ogni versione del sistema porta nuove API, le vecchie API diventano obsolete e scompaiono le API obsolete.

La modifica dell'API deve solo essere molto attenta sia tecnicamente che in termini di comunicazione.

La mia opinione sarebbe che una volta rilasciata, quella "versione" dell'API è per sempre, ma puoi deprecarla rilasciando un'API "2.0" (ci sono molti esempi in cui ciò sta accadendo - attualmente, posso pensare a Strava che ha rilasciato una versione 2.0 di un'API per lo sviluppo contro per consumare i loro servizi).

Il problema sta supportando quell'API originale all'infinito ... Immagino che dipenda dall'uso della vecchia API e dal valore che questi consumatori API detengono per te.

Tornando ai "vecchi tempi" di Windows 3.xe 9x ecc., Una volta rilasciati, quelle API del sistema operativo erano state fatte e impostate. Ora, gli aggiornamenti del sistema operativo vengono inviati continuamente, quindi possono essere rilasciate nuove API, ma penso che fintanto che stai eseguendo un particolare sapore del sistema operativo (versione principale), tali API verranno solo aggiunte, mai rimosse ... sia il caso della "prossima" major release.

Hmm, forse mi sono allontanato dall'intento della domanda originale.

Dipende dal tipo di API che è (e presumo che renda le modifiche, altrimenti l'affermazione ovviamente non è vera).

Se il chiamante può scegliere quale versione utilizzare (ad es. Con librerie / framework in bundle con l'applicazione chiamante), la modifica dell'API non è un grosso problema, ma è comunque negativa per la reputazione del software. Alla gente piace aggiornare senza problemi.

D'altra parte, quando le persone non riescono a continuare a utilizzare la vecchia versione dell'API (ad esempio con un servizio online o cose come un browser o un sistema operativo in cui l'esecuzione di versioni precedenti è molto indesiderabile), modificare le API in modo incompatibile è molto male infatti, dal momento che romperà tutto il software che lo utilizza e non viene aggiornato. Ciò comporta un costo di manutenzione per gli sviluppatori e ti odieranno per questo. E il software che non viene mantenuto e interrotto si rifletterà negativamente anche su di te.

D'altra parte, c'è almeno un fornitore di API che introduce costantemente cambiamenti radicali nell'API e ha comunque un successo ridicolo: Facebook. Ma gestiscono le modifiche con molta attenzione: esiste una politica pubblicata , le modifiche vengono annunciate e spiegate con almeno 90 giorni di anticipo e gli sviluppatori possono scegliere di attivarle in anticipo entro tale lasso di tempo.

Se hai la previsione di includere un numero di versione nell'API stessa. Sia sulla chiamata di connessione / inizializzazione o, da qualche parte vicino all'inizio dell'elenco dei parametri di ogni chiamata, l'API può evolversi e mutare nel tempo senza interrompere i client esistenti.

Anche se tutto ciò che facciamo è renderli migliori in una sola volta, ma poiché arrivano i cambiamenti e il miglioramento del tempo, a volte abbiamo bisogno di aggiornare le informazioni, come hanno fatto molti dei giganti fornitori, (come il face book di diversi aggiornamenti, Twitter uno dei principali passando a oAuth e molti altri importanti, ma al massimo tutto viene con un miglioramento, quindi nessun cambiamento frequente. E sì, per favore, non smettere di supportare quello più vecchio, fa male !! :)

Ogni volta che rilasci qualsiasi tipo di protocollo di comunicazione, che ovviamente includerebbe un'API, hai una possibilità di farlo correttamente, nel senso che il protocollo / l'interfaccia deve essere retrocompatibile ed estensibile.

Ciò consente di aggiungere nuove funzionalità e rilasciare nuove versioni senza doversi preoccupare di interrompere le persone che utilizzano versioni precedenti. Mai nel mondo del software si verificherà una situazione in cui è possibile avere un duro ritaglio ad un certo punto nel tempo e tutti abbandonano la vecchia versione e iniziano a utilizzare la nuova versione.