Ovviamente, le API sono esplose negli ultimi anni, ma molte di esse sembrano progettate male quando si tratta di utilizzarle ... Ho l'opportunità di progettare un'API, a mio avviso, ma mi piacerebbe che fosse facile da usare per coloro che vi accedono. Certo, mantenere il più semplice possibile è di grande aiuto, ma quali sono i trucchi che le persone hanno incontrato là fuori? Qualcosa che dovrebbe essere evitato a tutti i costi o implementato a tutti i costi?Progettazione di un'API solida, come?
risposta
Effettuare il checkout di questa tecnologia "How to Design a Good API and Why it Matters". Copre alcuni punti importanti ed è indipendente dalla lingua.
Le diapositive per la presentazione sopra sono disponibili here.
Alcuni punti che realmente risonanza con me:
- Se si programma, si sono un designer API
- buon codice è modulare ogni modulo ha un'API
- Difficile uso improprio
- Scrivere più plug-in prima del rilascio
- Facile da leggere
- codice dovrebbe leggere come prosa
Per eccellenti esempi di grandi API, vorrei suggerire di dare un'occhiata a queste API (è un wiki comunità quindi per favore sentitevi liberi di aggiungere):
per contrastare Crapis dalle buone API, vedono questo esempio comune di aver letto tutto lin es da un file e stampandoli. (Java):
BufferedReader reader = new BufferedReader(new FileReader("filePath"));
String line = null;
while ((line = reader.readLine()) != null) {
System.out.println(line);
}
ho fatto lima IO con Java in tante occasioni e ho ancora di ricercare come fare File IO ogni volta, e questo è un modo conciso di fare le cose, per davvero.
vs (Rubino)
file = File.open("filePath", "r");
puts file.readlines
Un altro esempio da JavaScript. Inserire e rimuovere elementi da una posizione specifica in una matrice è qualcosa che si suppone sia un'attività comune.
Ecco come si può fare:
// insert element at index
someArray.splice(index, 0, element);
// remove element at index
someArray.splice(index, 1);
Ora è impressionante che i progettisti hanno fatto un lavoro impressionante a riusabilità del codice, ma non posso disturbare apertura w3schools.com ogni volta che ho bisogno di fare Questo. Quindi, questi semplici wrapper vengono inclusi come estensioni fondamentali per Array in tutti i miei progetti:
Array.prototype.insertAt = function(element, index) {
this.splice(index, 0, element);
}
Array.prototype.removeAt = function(index) {
this.splice(index, 1);
}
Nota: Non si tratta di codice più corto, ma il codice che è più semplice, più facile da ricordare, leggibile, e coerente, tra l'altro cose.
Vedi anche correlata domanda - How do you define a good or bad API?
Si consiglia di fare riferimento a Framework Design Guidelines.
alt text http://davesbox.com/images/books/FrameworkDesignGuidelines2ndEditionLarge.jpg
Cioè, se sta usando .Net sono sicuro che se stai progettando un'API di Javascript le convenzioni e così via sono diverse (e ho dovuto soffrire attraverso alcune API javascript che seguivano. Convenzioni Nette) – Earlz
@ Earlz: Pensavo di essere l'unico a odiare il codice javascript che leggeva come C#; qualcuno può dire estensioni AJAX per asp.net? – Pierreten
@Pier nah AJAX ha solo un odore. Per apprezzare veramente il javascript net-icizzato devi vedere DevExpress http://demos.devexpress.com/aspxperiencedemos/NavBar/ClientSideAPI.aspx 'NavBar.SetSelectedItem (chbItemSelected.GetChecked()? GetNavBarItem(): null);' – Earlz
Forse si può cominciare elencando motivi per cui si dice "ma molti di loro sembrano mal progettato quando si tratta di loro utilizzando".
Nonostante questa domanda sia molto soggettiva, la cosa principale da tenere a mente è mantenere ciò che le API sono progettate per fare più facilmente (scrivere piccole quantità di codice in modo semplice) e fare in modo di fare le cose non è stato originariamente progettato per fare.
Per darvi un esempio molto semplicistico, supponiamo che stiate scrivendo un'API in C# e che abbiate un metodo che restituisce una collezione di elementi. Quale tipo dovresti tornare? In questo caso puoi porre la seguente domanda per aiutarti a decidere: vorrei che l'utente della mia API modificasse la raccolta (aggiungi o rimuovi gli articoli)? Se la tua risposta non è, dovresti restituire un oggetto ReadOnlyCollection degli articoli, altrimenti dovresti restituire un elenco di elementi.
Continua a chiedere questo tipo di domande per aiutarti a progettare meglio la tua API. E ricorda sempre gli obiettivi che avevi inizialmente impostato per la tua API. Cercare di essere generosi è una ragione molto comune dietro molte API diventare Frankstein.
Come un altro utente ha detto nella sua risposta allo sviluppo di un'API insieme a un sistema reale è sempre l'approccio migliore.
divertente. Ho appena letto questo articolo di Eric Lippert, in pratica dicendo che non dovresti quasi mai voler restituire un array in C#. Gli lascerò parlare meglio che potrei: http://blogs.msdn.com/ericlippert/archive/2008/09/22/arrays-considered-somewhat-harmful.aspx – Toad
Il mio intento non stava dicendo che il ritorno un array era una buona pratica, ma fornire un semplice esempio rudimentale di cercare di pensare a come il codice sarebbe stato usato. Ho capito il tuo punto e aggiornerò la risposta per utilizzare ReadOnlyCollection. –
In realtà, non restituirei nemmeno ReadOnlyCollection; restituire un oggetto IEnumerable <> è più di una pratica standard e fornisce un'indicazione abbastanza chiara a un consumatore su cosa dovrebbero fare con il valore restituito. – Pierreten
Per creare un'ottima API, credo sia fondamentale svilupparla insieme a una o più applicazioni del mondo reale. In questo modo puoi testare quanto pienamente ed elegantemente la tua API affronta problemi comuni.
ENORME più uno. Le uniche API che utilizzo che sono state progettate da me sono state prese in considerazione dalle applicazioni reali. – Pierreten
Meglio "più" di "uno", idealmente sviluppato da diversi sviluppatori rispetto al progettista API. –
Scrivi il cliente-primo codice. Chiedi ai tuoi pari di scrivere il codice cliente che deve utilizzare la tua API ed evolvere il tuo progetto dal codice cliente.
Se si sta scrivendo un'API matematica, chiedere ai peer di scrivere codice client come se lo stessero utilizzando. Questo ti darà alcune buone idee per cominciare.
Estendere il post di Anurag, ecco un elenco di alcune note che dovrebbero essere tenute a mente durante la progettazione/esecuzione un'API
https://github.com/srijanlabs/docs/wiki/API-Guidelines
Si ispira grande presentazione da Joshua Bloch. Normalmente lo tengo a portata di mano durante la fase iniziale della progettazione dell'API. Il documento è progettato in un modo di lista di controllo, assicurati di seguire "Come usare questo documento?" dato in alto.
- 1. Come eseguire una solida archiviazione locale dei thread in iOS
- 2. Come posso ottenere che la mia collisione sia più solida?
- 3. Come insegnare modelli di progettazione a una squadra
- 4. Progettazione API Java - Progettazione interna
- 5. Progettazione del database di timeseries in Cassandra
- 6. Modelli di progettazione SQL
- 7. domanda di progettazione OOP
- 8. Progettazione modello di errore
- 9. Motivo di progettazione MapMaker?
- 10. Motivo di progettazione "Facciata"
- 11. Modello di progettazione DAO
- 12. Associazione dati come modello di progettazione
- 13. Progettazione di una web api: come autenticarsi?
- 14. Dove posso trovare una documentazione valida e solida per le primitive di sincronizzazione di C++ 0x?
- 15. Modelli di progettazione messaggio
- 16. Modelli di progettazione JavaScript
- 17. Modello di progettazione lavoratore
- 18. Modelli di progettazione per la progettazione simultanea agente/attore
- 19. Progettazione Qt - come creare QDialog?
- 20. Progettazione Bytecode?
- 21. decisione di progettazione di jvm
- 22. compilatore progettazione
- 23. Software di progettazione in C
- 24. Modelli di progettazione dati/database?
- 25. Sito Web di progettazione software
- 26. Domanda di progettazione livello database
- 27. NetFx40_LegacySecurityPolicy in modalità di progettazione
- 28. Progettazione di costruttori per testabilità
- 29. Esiste un'opzione di progettazione migliore?
- 30. Intuizione vs principi di progettazione
Di cosa stiamo parlando? web apis? Apis sul lato server? – Pierreten
troppo aperto. Anche la lingua può aiutare (in modo da sfruttare le sue funzioni) – Earlz
Penso che il discorso di oggi da Google IO (Come le API di Google costruiscono) avrà una certa rilevanza qui, anche se non è ancora su Youtube - (http://code.google.com /events/io/2010/sessions/how-google-builds-apis.html). – Anurag