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

20

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

    
posta Md Mahbubur Rahman 23.02.2013 - 07:34
fonte

8 risposte

32

Generalmente è vero per qualsiasi API pubblica, sì. Una volta che esponi un'API al pubblico e le persone iniziano a creare applicazioni che dipendono da tale API, diventa estremamente difficile modificare l'API perché così facendo si interromperanno tutte quelle applicazioni. Ciò tende ad essere sia un problema tecnico difficile che un difficile problema politico.

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

    
risposta data 23.02.2013 - 08:15
fonte
12

L'autore dell'autore è Joshua Bloch, l'affermazione è tratta dal suo articolo Bumper-Sticker API Design :

Public APIs, like diamonds, are forever. You have one chance to get it right so give it your best.

Per maggiori dettagli, l'autore rimanda i lettori alla sua presentazione della sessione della conferenza, "Come progettare una buona API e Perché è importante ". Diapositiva Perché il design dell'API è importante per Tu afferma chiaramente che questo è rilevante per qualsiasi attività di programmazione (sistemi operativi o meno, non ha importanza per l'autore):

  • If you program, you are an API designer

    • Good code is modular - each module has an API
  • Useful modules tend to get reused

    • Once module has users, can’t change API at will
    • Good reusable modules are corporate assets
  • Thinking in terms of APIs improves code quality

La diapositiva Conclusione lo sottolinea anche come approccio generale:

  • API design is a noble and rewarding craft

    • Improves the lot of programmers, end-users, companies...
    
risposta data 23.02.2013 - 09:16
fonte
3

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

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

Il cambiamento dell'API deve solo essere molto attento sia dal punto di vista tecnico che in termini di comunicazione.

    
risposta data 23.02.2013 - 18:20
fonte
2

La mia opinione sarebbe che una volta rilasciata, quella "versione" dell'API è per sempre, ma puoi deprecarla pubblicando un'API "2.0" (ci sono diversi esempi in cui ciò accade - al momento, posso pensare a Strava chi ha rilasciato una versione 2.0 di un'API per lo sviluppo contro di consumare i propri servizi).

Il problema sta supportando l'API originale all'infinito ... Suppongo che dipenda dall'utilizzo della vecchia API e dal valore di tali utenti API che ti stanno tenendo.

Tornando ai "vecchi tempi" di Windows 3.x e 9x ecc., una volta rilasciata, quelle API del sistema operativo sono state eseguite e impostate. Ora gli aggiornamenti del sistema operativo vengono continuamente aggiornati, quindi è possibile rilasciare nuove API, ma penso che finchè si esegue un particolare SO del sistema operativo (versione principale), tali API verranno solo aggiunte, non rimosse mai ... essere il caso della "prossima" major release.

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

    
risposta data 23.02.2013 - 19:34
fonte
1

Dipende dal tipo di API che è (e sto assumendo cambiamenti di rottura, altrimenti l'affermazione non è ovviamente vera).

Se il chiamante può scegliere la versione che sta utilizzando (ad es. con librerie / framework che sono in bundle con l'applicazione chiamante), cambiare l'API non è un problema enorme, ma è comunque negativo per la reputazione del software. Alla gente piace aggiornare senza problemi.

D'altra parte, quando le persone non possono continuare ad usare la vecchia versione dell'API (come con un servizio online, o cose come un browser o un sistema operativo dove eseguire vecchie versioni è molto indesiderabile), quindi cambiando le API in modo incompatibile è davvero molto brutto, poiché romperà tutto il software che lo usa e non verrà aggiornato. Ciò impone un costo di manutenzione per gli sviluppatori e ti odieranno per questo. E il software che non viene mantenuto e le pause rifletteranno male anche su di te.

Sulla mano che stringe, c'è almeno un fornitore di API che costantemente introduce cambiamenti irrisolti nell'API ed è comunque ridicolmente vincente: Facebook. Ma gestiscono le modifiche con molta attenzione: c'è una politica pubblicata , i cambiamenti di rottura sono annunciati e spiegati almeno 90 giorni prima e gli sviluppatori possono scegliere di attivarli presto entro quel periodo di tempo.

    
risposta data 23.02.2013 - 22:22
fonte
1

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

    
risposta data 25.02.2013 - 03:55
fonte
0

Sebbene tutto ciò che facciamo sia quello di renderli migliori in una volta sola, ma dal momento che i cambiamenti e i miglioramenti del tempo arrivano, a volte abbiamo bisogno di aggiornare le informazioni, come hanno fatto molti dei giganti fornitori (come ad esempio diversi aggiornamenti, twitter one major turning to oAuth e parecchi major, ma al massimo tutto viene fornito con miglioramenti, quindi nessun cambiamento frequente. E sì, per favore non smettere di supportare uno più vecchio, Fa male !!:)

    
risposta data 23.02.2013 - 17:10
fonte
-1

Ogni volta che si rilascia qualsiasi tipo di protocollo di comunicazione, che ovviamente include un'API, si ha la 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 rompere le persone che utilizzano versioni precedenti. Mai nel mondo del software hai una situazione in cui puoi avere un duro passaggio ad un certo punto nel tempo, e tutti abbandonano la vecchia versione e inizia ad usare la nuova versione.

    
risposta data 02.03.2013 - 18:45
fonte

Leggi altre domande sui tag