Sandbox

acciaio, visone, manzo, carta 26 novembre 2012 alle 13:59

Cos'è l'API

Saluti!
In questo articolo, vedremo cos'è un'API, dove, come e per cosa viene utilizzata. Vedremo anche come l'API può essere applicata nel tuo sviluppo web e come può semplificare la vita di un programmatore web.

Allora partiamo dalla definizione. API (Application Programming Interface) è un'interfaccia di programmazione, un'interfaccia per la creazione di applicazioni. In un linguaggio più comprensibile, l'API è un codice già pronto per semplificare la vita di un programmatore. L'API è stata creata in modo che un programmatore potesse davvero facilitare il compito di scrivere un'applicazione utilizzando codice già pronto (ad esempio, funzioni). Anche il noto jQuery scritto in JavaScript è una sorta di API. Se consideriamo questo particolare esempio, jQuery rende molto più semplice scrivere codice. Ciò che potrebbe essere fatto in 30 righe con i normali mezzi JavaScript è scritto tramite jQuery in 5-6. Se esaminiamo l'API in generale, puoi trovare molti servizi che rappresentano soluzioni per lo sviluppo. Il più famoso oggi è il servizio code.google.com, che fornisce una cinquantina di API diverse! Questa è un'interfaccia per la creazione di applicazioni Android e varie API per lavorare con AJAX e varie API di applicazioni che puoi facilmente personalizzare a tuo piacimento.

Dopotutto, ha senso scrivere codice con le proprie mani? Perché lavorare su ciò che è già stato creato? Ha senso rinunciare a soluzioni gratuite (e di fatto, aiuto gratuito) nello sviluppo web? Se hai risposto "NO" a tutte queste domande, presumi di aver compreso l'essenza dell'API.

Ma voglio anche fare una prenotazione. Gli sviluppatori alle prime armi NON dovrebbero utilizzare soluzioni semilavorate, poiché non affronteranno il vero compito in futuro. Pertanto, se sei un programmatore web principiante, non utilizzare prodotti semilavorati! Impara a pensare con la tua testa, costruisci vari algoritmi per capire l'essenza della programmazione. Dico anche, rivolgendomi già a tutti, che le API non sono soluzioni già pronte, è un ambiente, un'interfaccia per creare i propri progetti. Non mangi hamburger surgelati dal negozio, vero? Prima li friggi, vero? Questa analogia è molto chiara sull'essenza dell'API.

In generale, ti ho detto che cos'è un'API, dove e come viene utilizzata, la cosa più importante per cosa. Vi auguro un piacevole studio della programmazione web e la comprensione delle sue sempre maggiori profondità!

tag: api

Questo articolo non è soggetto a commenti, poiché il suo autore non è ancora un membro a pieno titolo della comunità. Potrai contattare l'autore solo dopo averlo ricevuto

API di Windows: un insieme di funzioni del sistema operativo

L'API di abbreviazione sembra a molti programmatori alle prime armi molto misteriosa e persino intimidatoria. In effetti, l'Application Programming Interface (API) è solo un insieme di funzioni già pronte che gli sviluppatori di applicazioni possono utilizzare. In generale, questo concetto è equivalente a quella che veniva chiamata una libreria di routine. Tuttavia, l'API di solito fa riferimento a una categoria speciale di tali librerie.

Durante lo sviluppo di quasi tutte le applicazioni sufficientemente complesse (MyApplication) per l'utente finale, viene formato un insieme di funzioni interne specifiche utilizzate per implementare questo particolare programma, chiamato MyApplication API. Tuttavia, spesso si scopre che queste funzioni possono essere efficacemente utilizzate per creare altre applicazioni, anche da altri programmatori. In questo caso, gli autori, in base alla strategia di promozione del loro prodotto, devono decidere la domanda: aprono l'accesso a questo set agli utenti esterni o no? Se la risposta è sì nella descrizione del pacchetto software, la frase appare come una caratteristica positiva: "Il kit include un insieme aperto di funzioni API" (ma a volte per denaro aggiuntivo).

Pertanto, molto spesso, un'API indica un insieme di funzioni che fanno parte di un'applicazione, ma allo stesso tempo sono disponibili per l'uso in altri programmi. Ad esempio, Excel, oltre a un'interfaccia per l'utente finale, dispone di un insieme di funzioni API di Excel che possono essere utilizzate, in particolare, durante la creazione di applicazioni utilizzando VB.

Di conseguenza, l'API di Windows è un insieme di funzioni che fa parte del sistema operativo stesso e allo stesso tempo è disponibile per qualsiasi altra applicazione, comprese quelle scritte utilizzando VB. A questo proposito, l'analogia con il set di interrupt di sistema BIOS/DOS, che in realtà è un'API DOS, è abbastanza giustificata.

La differenza sta nel fatto che la composizione delle funzioni API di Windows, da un lato, è molto più ampia rispetto al DOS, dall'altro non include molti degli strumenti per il controllo diretto delle risorse informatiche che erano a disposizione programmatori nel sistema operativo precedente. Inoltre, è possibile accedere all'API di Windows utilizzando normali chiamate procedurali e le chiamate alle funzioni DOS vengono effettuate tramite uno speciale comando della macchina del processore chiamato Interrupt.

Perché hai bisogno di Win API per i programmatori VB?

Nonostante il fatto che VB abbia un'enorme varietà di funzioni, nel processo di sviluppo più o meno serio, si scopre che le loro capacità spesso non sono sufficienti per risolvere i compiti necessari. Allo stesso tempo, i programmatori alle prime armi iniziano spesso a lamentarsi delle carenze di VB e pensano di cambiare lo strumento, senza sospettare che ci sia un enorme set di strumenti sul loro computer e devi solo essere in grado di usarli.

Conoscendo l'API Win, si scopre che molte funzioni VB integrate non sono altro che chiamate alle procedure di sistema corrispondenti, ma implementate solo nella forma della sintassi di questo linguaggio. Con questo in mente, la necessità di utilizzare l'API è determinata dalle seguenti opzioni:

1. Funzioni API completamente implementate come funzioni VB integrate. Tuttavia, a volte, in questo caso, è anche utile passare all'utilizzo dell'API, poiché questo a volte può aumentare notevolmente le prestazioni (in particolare, a causa dell'assenza di trasformazioni non necessarie dei parametri passati).
2. Le funzioni VB integrate implementano solo un caso speciale della funzione API corrispondente. Questa è un'opzione abbastanza comune. Ad esempio, l'API CreateDirectory è più potente dell'operatore VB MkDir integrato.
3. Un numero enorme di funzioni API non ha alcun analogo nella versione corrente del linguaggio VB. Ad esempio, non è possibile eliminare una directory utilizzando VB: è necessario utilizzare la funzione EliminaDirectory per farlo.

Va inoltre sottolineato che alcune funzioni API (la loro quota nell'API Win è molto piccola) non possono essere chiamate dai programmi VB a causa di una serie di restrizioni linguistiche, ad esempio a causa della mancanza della capacità di lavorare con gli indirizzi di memoria. Ma in alcuni casi, tecniche di programmazione non banali possono aiutare (in particolare, nel caso degli stessi indirizzi).

Il punto di vista personale dell'autore è che invece di espandersi da una versione all'altra delle funzioni VB integrate, dovrebbe essere data una buona descrizione delle funzioni API più comuni. Allo stesso tempo, vorrei consigliare agli sviluppatori di non aspettare una nuova versione dello strumento con funzioni avanzate, ma di studiare più da vicino l'API Win esistente: è probabile che le capacità di cui hai bisogno siano state già implementate nel Versione VB 1.0 della versione 1991.

Come imparare Win API

Non è una domanda così facile, considerando che il numero di funzioni API Win32 è stimato in circa 10mila (nessuno conosce la cifra esatta, nemmeno Microsoft).

Il VB (versioni 4-6) include un file con la descrizione delle dichiarazioni API Win - WIN32API.TXT (ti diremo di più sul suo utilizzo in seguito). Ma, in primo luogo, può essere utilizzato per ottenere informazioni sullo scopo di una particolare funzione e sui suoi parametri solo dai nomi mnemonici utilizzati e, in secondo luogo, l'elenco delle funzioni in questo file è lungi dall'essere completo. Un tempo (sette anni fa) in VB 3.0 c'erano file di aiuto speciali che descrivevano le funzioni dell'API Win16. Tuttavia, già nella v.4.0 queste informazioni utili con un'interfaccia user-friendly sono scomparse.

Informazioni complete sull'API Win32 sono disponibili nella Guida di Platform Software Development Kit, che si trova in particolare sui CD di MSDN Library inclusi con VB 5.0 e 6.0 Enterprise Edition e Office 2000 Developer Edition. Tuttavia, non è affatto facile trovare le informazioni necessarie e comprenderle. Per non parlare del fatto che tutte le descrizioni sono fornite in relazione al linguaggio C.

I libri del noto esperto americano Daniel Appleman sono generalmente riconosciuti nel mondo come una guida per l'apprendimento della programmazione API in ambiente VB. La sua serie Visual Basic Programmer's Guide to the Windows API di Dan Appleman (per Win16, Win32, applicata a diverse versioni di VB) è stata costantemente uno dei bestseller per i programmatori VB dal 1993. La VB 5.0 Programmer's Guide to the Win32 API di Dan Appleman, pubblicata nel 1997, è stata portata all'autore dagli Stati Uniti da un amico che l'ha trovata nella prima libreria di una piccola città di provincia.

Questo libro, di oltre 1.500 pagine, include una metodologia generale per la programmazione API in ambiente VB, oltre a oltre 900 funzioni. Il CD-ROM allegato contiene il testo completo del libro e tutti gli esempi di programma, oltre a diversi capitoli aggiuntivi che non erano inclusi nella versione stampata. Nel 1999, Dan Appleman ha rilasciato Win32 API Puzzle Book and Tutorial for Visual Basic Programmers di Dan Appleman, che include informazioni su altre 7.600 funzioni (sebbene meno approfondite).

Win API e libreria di collegamenti dinamici (DLL)

Il set di API Win è implementato come DLL dinamiche. Inoltre, parleremo effettivamente della tecnologia di utilizzo delle DLL nell'ambiente VB utilizzando l'esempio delle librerie che fanno parte dell'API Win. Tuttavia, ci sono alcuni punti importanti da fare quando si parla di DLL.

In questo caso, per DLL, intendiamo la versione tradizionale delle librerie dinamiche binarie che forniscono chiamate dirette dell'applicazione alle procedure necessarie - subroutine o funzioni (più o meno allo stesso modo di quando si chiamano procedure all'interno di un progetto VB). Tali librerie possono essere create utilizzando diversi strumenti: VC++, Delphi, Fortran, ad eccezione di VB (vediamo cosa appare nella versione 7.0) - quest'ultimo può eseguire solo DLL ActiveX, a cui si accede tramite l'interfaccia OLE Automation.

Solitamente i file DLL hanno l'estensione .DLL, ma ciò non è necessario (per Win16 si usava spesso l'estensione .EXE); i driver del dispositivo esterno sono identificati con .DRV.

Come abbiamo notato, è difficile determinare il numero esatto di funzioni API di Windows e i file che le contengono, ma si trovano tutti nella directory di sistema. A tal proposito è bene evidenziare la composizione delle librerie incluse nel kernel del sistema operativo, e le librerie principali con funzioni chiave aggiuntive.

Ora per alcuni suggerimenti.

Suggerimento 1. Assicurati che il tuo annuncio DL sia formattato correttamente L-procedure

La chiamata effettiva alle procedure DLL nel programma ha lo stesso aspetto delle "solite" procedure di Visual Basic, ad esempio:

Chiama DllName ([elenco argomenti])

Tuttavia, per utilizzare funzioni DLL esterne (inclusa l'API Win), devono essere dichiarate nel programma utilizzando l'istruzione Declare, che ha il seguente aspetto:

Dichiara Sub ProcedureName Lib _ “LibraryName” _ [([ArgumentList])]

Dichiara funzione FunctionName _ Lib “LibraryName” _ [([ArgumentList])]

Qui, tra parentesi quadre, sono indicati gli elementi opzionali dell'operatore, le espressioni variabili sono in corsivo, il resto delle parole sono parole chiave. Il sistema di aiuto fornisce una descrizione abbastanza buona della sintassi dell'operatore, quindi per ora ci limiteremo a notare alcuni punti.

Le dichiarazioni di funzioni esterne devono essere inserite nella sezione Dichiarazioni generali del modulo. Se lo inserisci in un modulo modulo, devi specificare la parola chiave Private (questa dichiarazione sarà disponibile solo all'interno di questo modulo) - questa è una limitazione per tutte le procedure del modulo modulo.

Il set di API Win32 è implementato solo come funzioni (c'erano molti Sub nell'API Win16). La maggior parte di esse sono funzioni di tipo Long, che molto spesso restituiscono un codice di completamento dell'operazione.

La dichiarazione Declare è apparsa in MS Basic ai tempi del DOS ed è stata utilizzata anche per dichiarare le procedure interne di un progetto. In Visual Basic, ciò non è necessario perché la dichiarazione delle procedure interne è automaticamente la loro descrizione Sub o Function. Rispetto al Basic/DOS, nella nuova descrizione è obbligatorio indicare il nome del file di libreria dove si trova la procedura richiesta. Le librerie dell'API Wip si trovano nella directory di sistema di Windows, quindi è sufficiente solo il nome del file. Se fai riferimento a una DLL situata in una posizione arbitraria, devi annotare il percorso completo di questo file.

La descrizione dell'istruzione Declare in genere occupa molto spazio e non si adatta a una riga nella finestra del codice. Pertanto, si consiglia di attenersi a uno schema di avvolgimento della riga specifico durante la scrittura delle applicazioni, ad esempio:

Dichiara la funzione GetTempPath _ Lib “kernel32” Alias ​​​​“GetTempPathA” _ (ByVal nBufferLength As Long, _ ByVal lpBuffer As String) As Long

In questo caso, tutti gli elementi principali della descrizione sono distanziati su righe diverse e quindi di facile lettura.

Suggerimento 2. Prestare particolare attenzione quando si lavora con le funzioni DLL

L'uso dell'API Win e di varie funzioni DLL espande notevolmente la funzionalità di VB e spesso migliora le prestazioni dei programmi. Tuttavia, la penalità per questo è il rischio di una ridotta affidabilità dell'applicazione, specialmente durante il debug.

Uno dei vantaggi più importanti dell'ambiente VB è l'affidabilità del processo di sviluppo del programma: operando sotto il controllo di un interprete, il codice del programma teoricamente non può interrompere il lavoro di Windows e VB stesso. Il programmatore potrebbe non essere molto attento alla correttezza del passaggio dei parametri alle funzioni chiamate: tali errori saranno facilmente rilevati dall'interprete stesso, sia durante la traduzione del codice, sia durante la sua esecuzione. Nel caso più spiacevole, la modalità di elaborazione verrà semplicemente interrotta, con l'indicazione di dove e perché si è verificato l'errore.

L'utilizzo delle API di Windows o di altre DLL rimuove direttamente questo controllo sul trasferimento dei dati e sull'esecuzione del codice al di fuori dell'ambiente VB. Pertanto, un errore nella chiamata a funzioni esterne può portare all'inoperabilità sia di VB che del sistema operativo. Ciò è particolarmente vero nella fase di sviluppo del programma, quando la presenza di errori è del tutto naturale. Pertanto, utilizzando le più ampie capacità delle funzioni del livello base del sistema, il programmatore si assume la responsabilità del loro corretto utilizzo.

Il problema è aggravato dal fatto che diversi linguaggi di programmazione utilizzano modi diversi per passare i parametri tra le procedure. (Più precisamente, per impostazione predefinita vengono utilizzati diversi metodi di trasferimento, poiché molti linguaggi possono supportare più metodi.) Le API Win sono implementate in C / C ++ e utilizzano le convenzioni di passaggio dei parametri di quel sistema, che differiscono dal solito VB versione.

A questo proposito, va notato che la comparsa di analoghi delle funzioni API integrate in VB è giustificata proprio dall'adattamento di quest'ultimo alla sintassi VB e dall'implementazione del corrispondente meccanismo di controllo dello scambio di dati. Si noti inoltre che nella fase di debug sperimentale dell'applicazione, durante la creazione di un modulo eseguibile, è preferibile utilizzare l'opzione di compilazione del codice P anziché il codice nativo (codice macchina). Nel primo caso, il programma verrà eseguito sotto il controllo dell'interprete, più lento del codice macchina, ma più affidabile dal punto di vista del possibile impatto errato sul sistema operativo e fornendo una modalità più conveniente per identificare possibili errori.

Suggerimento 3: le dieci migliori pratiche di Dan Appleman per una programmazione API robusta in VB

L'utilizzo di una funzione API richiede una programmazione più attenta utilizzando alcuni metodi non così familiari per chiamare le procedure (rispetto a VB). Inoltre affronteremo costantemente queste domande. E ora presentiamo un riassunto dei consigli su questo argomento formulati da Dan Appleman (la loro prima versione è apparsa nel 1993) con alcune delle nostre aggiunte e commenti.

1. Ricorda ByVal. L'errore più comune commesso quando si accede alle funzioni API e DLL è l'uso errato della parola chiave ByVal: o dimenticano di inserirla o, al contrario, la inseriscono quando non è necessaria.

Questi esempi mostrano l'effetto dell'operatore ByVal sul passaggio dei parametri

Tipo di parametro	Con ByVal	Senza ByVal
Numero intero	Inserisce un intero a 16 bit nello stack	Spinto nello stack l'indirizzo a 32 bit di un numero intero a 16 bit
Lungo	Un intero a 32 bit viene inserito nello stack	Spinto nello stack l'indirizzo a 32 bit di un numero intero a 32 bit
Corda	La stringa viene convertita nel formato utilizzato in C (dati e un byte nullo di terminazione). L'indirizzo di nuova riga a 32 bit viene inserito nello stack	Il descrittore di riga VB viene inserito nello stack. (Tali descrittori non vengono mai utilizzati dall'API di Windows stessa e sono riconosciuti solo nelle DLL implementate specificamente per VB.)

Va ricordato qui che i parametri vengono passati in qualsiasi sistema di programmazione, incluso VB, in due modi principali: per riferimento (ByRef) o per valore (ByVal). Nel primo caso, viene passato l'indirizzo della variabile (questa opzione è utilizzata di default in VB), nel secondo - il suo valore. La differenza fondamentale è che tramite un riferimento, il valore modificato del parametro passato viene restituito al programma chiamante.

Per capirlo, esegui un esperimento utilizzando i seguenti programmi:

Dim v As Integer v = 2 Call MyProc (v) MsgBox “v =“ & v Sub MyProc (v As Integer) v = v + 1 End Sub

Eseguendo questo esempio si riceverà un messaggio con il valore della variabile pari a 3. Il fatto è che in questo caso l'indirizzo della variabile v, creata fisicamente nel programma chiamante, viene passato alla subroutine MyProc. Ora cambia la descrizione della procedura in

Sub MyProc (ByVal v As Integer)

Di conseguenza, durante l'esecuzione del test, riceverai v = 2, poiché solo il valore originale della variabile viene passato alla procedura: il risultato delle operazioni eseguite con esso non viene restituito al programma chiamante. La modalità di trasferimento per valore può essere modificata anche utilizzando l'operatore di chiamata come segue:

Sub MyProc (v As Integer) ... Chiama MyProc ((v)) '(v) - le parentesi indicano il trasferimento per valore _ modalità.

Tuttavia, quando si fa riferimento a procedure VB interne, la parola chiave ByVal non è consentita nell'istruzione Call: vengono invece utilizzate le parentesi. C'è una spiegazione per questo.

Nel caso classico (C, Fortran, Pascal), la differenza tra ByRef e ByVal dipende da cosa viene esattamente inserito nello stack di scambio dati: l'indirizzo di una variabile o il suo valore. In Basic, storicamente viene utilizzata la versione ByVal dell'emulazione software: l'indirizzo è sempre nello stack, ma solo quando viene passato per valore, viene creata una variabile temporanea per questo. Per distinguere queste due opzioni (Classic e Basic), vengono utilizzati diversi modi di descrivere la modalità ByVal. Si noti che l'emulazione della modalità ByVal in VB fornisce una maggiore affidabilità del programma: confondendo la forma della chiamata, il programmatore rischia solo che il valore corretto della variabile torni (o meno) al programma chiamante. Nella versione "classica", tale confusione può portare a un errore fatale durante l'esecuzione della procedura (ad esempio, quando al posto di un indirizzo di memoria viene utilizzato un valore di variabile pari, ad esempio, a zero).

Le funzioni DLL sono implementate secondo principi "classici" e quindi richiedono una descrizione obbligatoria di come i dati vengono scambiati con ciascuno degli argomenti. È a questo scopo che servono le dichiarazioni di funzione tramite la descrizione Declare (più precisamente, un elenco di argomenti passati). Molto spesso, il passaggio di parametri a un'API di Windows o a una funzione DLL viene eseguito utilizzando la parola chiave ByVal. Inoltre, può essere specificato sia nell'istruzione Declare che direttamente quando si chiama la funzione.

Le conseguenze del passaggio errato dei parametri sono facili da prevedere. Se ricevi un indirizzo chiaramente non valido, ti verrà richiesto con un messaggio GPF (General Protection Fault). Se la funzione riceve un valore che corrisponde a un indirizzo valido, la funzione API entrerà nell'area di qualcun altro (ad esempio, il kernel di Windows) con tutte le conseguenze catastrofiche che ne conseguono.

2. Controllare il tipo dei parametri passati. Il numero corretto e il tipo di parametri passati sono ugualmente importanti. Gli argomenti dichiarati in Declare devono corrispondere ai parametri previsti nella funzione API. L'errore più comune nel passaggio dei parametri è legato alla differenza tra NULL e stringhe di lunghezza zero: ricorda che non sono la stessa cosa.

3. Controllare il tipo di reso.

VB è abbastanza tollerante per le discrepanze di tipo nei valori restituiti dalle funzioni, poiché i valori numerici vengono solitamente restituiti tramite registri anziché tramite lo stack. Le seguenti regole ti aiuteranno a determinare il valore corretto restituito da una funzione API:

• Una funzione DLL che non restituisce un valore (analogo a void in 'C') deve essere dichiarata come VB Sub.
• una funzione API che restituisce un valore intero (Integer o Long) può essere definita come Sub o come Function che restituisce un valore del tipo appropriato.
• nessuna delle funzioni API restituisce numeri a virgola mobile, ma alcune DLL potrebbero restituire questo tipo di dati.

4. Usa la costruzione "As Any" con grande cura. Molte funzioni API di Windows hanno la capacità di accettare parametri di vari tipi e utilizzare il costrutto As Any (il tipo viene interpretato in base al valore di altri parametri passati).

Una buona soluzione in questo caso sarebbe quella di utilizzare più alias di funzione, creando due o più dichiarazioni per la stessa funzione, ciascuna delle descrizioni che specifica parametri di un tipo specifico.

5. Non dimenticare di inizializzare le stringhe. Esistono molte funzioni nell'API Win che restituiscono informazioni caricando i dati in buffer di stringhe passati come parametro. Nel tuo programma, puoi sembrare che tu faccia tutto bene: non dimenticare ByVal, passa correttamente i parametri alla funzione. Ma Windows non può controllare quanto è grande la memoria allocata per la stringa. La dimensione della linea deve essere sufficientemente grande da contenere tutti i dati che possono essere inseriti in essa. È responsabilità del programmatore VB riservare un buffer della dimensione corretta.

Va notato che in Windows a 32 bit, quando si utilizzano le stringhe, la conversione viene eseguita da Unicode (codifica a doppio byte) ad ANSI (a byte singolo) e viceversa, tenendo conto delle impostazioni nazionali del sistema. Pertanto, a volte è più conveniente utilizzare matrici di byte anziché variabili stringa per riservare i buffer. (Più su questo sotto.)

Molto spesso, le funzioni dell'API Win ti consentono di definire tu stesso la dimensione massima del blocco. In particolare, a volte è necessario chiamare un'altra funzione API per questo, che "richieda" la dimensione del blocco. Ad esempio, GetWindowTextLength consente di determinare la dimensione della riga necessaria per contenere il titolo della finestra, che viene recuperato dalla funzione GetWindowText. In questo caso, Windows si assicura che tu non vada all'estero.

6. Assicurati di utilizzare l'opzione esplicita.

7. Controllare i valori dei parametri e restituire i valori con attenzione. VB ha buone capacità di controllo del tipo. Ciò significa che quando si tenta di passare un parametro non valido a una funzione VB, la cosa peggiore che può accadere è che si riceva un errore da VB. Ma questo meccanismo, purtroppo, non funziona quando si accede alle funzioni API di Windows.

Windows 9x ha migliorato la convalida dei parametri per la maggior parte delle funzioni API. Pertanto, la presenza di un errore nei dati di solito non causa un errore fatale, ma non è così facile determinare cosa l'ha causato.

Qui puoi consigliare di utilizzare diversi modi per eseguire il debug di questo tipo di errore:

• utilizzare la modalità di debug a passaggio singolo o il comando Debug.Print per controllare ogni chiamata API sospetta. Controllare i risultati di queste chiamate per assicurarsi che tutto rientri nei limiti normali e che la funzione sia stata completata correttamente;
• utilizzare un debugger di Windows come CodeView e un debugger di Windows (disponibile in Windows SDK). Questi strumenti possono rilevare gli errori dei parametri e almeno determinare quale funzione API sta causando l'errore;
• utilizzare strumenti aggiuntivi di terze parti per verificare i tipi di parametri e la validità dei loro valori. Tali strumenti non solo possono trovare errori di parametro, ma anche puntare alla riga di codice VB in cui si è verificato l'errore.

Inoltre, è indispensabile controllare il risultato della funzione API.

8. Ricorda che gli interi in VB e Windows non sono la stessa cosa. Prima di tutto, va tenuto presente che il termine "Integer" in VB significa un numero a 16 bit, nella documentazione di Win 32 - 32 bit. In secondo luogo, gli interi (Integer e Long) in VB sono quantità con segno (ovvero, una cifra viene utilizzata come segno, il resto viene utilizzato come mantissa di un numero), in Windows vengono utilizzati solo numeri non negativi. Questa circostanza deve essere tenuta presente quando si forma il parametro passato utilizzando operazioni aritmetiche (ad esempio, calcolando l'indirizzo aggiungendo una base e un offset). Le funzioni aritmetiche standard VB non sono adatte a questo. Come essere in questo caso, parleremo separatamente.

9. Prestare molta attenzione ai nomi delle funzioni. A differenza di Win16, i nomi di tutte le funzioni API Win32 sono sensibili all'uso esatto delle lettere maiuscole e minuscole (che non era il caso in Win16). Se da qualche parte usi una lettera minuscola invece di una maiuscola o viceversa, la funzione richiesta non verrà trovata. Assicurati inoltre di utilizzare correttamente il suffisso A o W nelle funzioni che utilizzano parametri di stringa. (Vedi sotto per maggiori informazioni su questo.)

10. Salva il tuo lavoro più spesso. Errori relativi all'uso non corretto di DLL e Win API possono portare a una chiusura anomala dell'ambiente VB e possibilmente dell'intero sistema operativo. È necessario assicurarsi che il codice che si scrive venga salvato prima dell'esecuzione del test. La cosa più semplice è impostare la modalità di registrazione automatica dei moduli del progetto prima di avviare il progetto nell'ambiente VB.

Dopo aver letto il suggerimento precedente, potresti pensare che l'utilizzo delle funzioni dell'API Win sia un'attività rischiosa. In una certa misura, questo è vero, ma solo in confronto alla programmazione sicura fornita da VB stesso. Ma con la loro abile applicazione e la conoscenza delle possibili insidie, questo rischio è minimo. Inoltre, spesso è semplicemente impossibile abbandonare completamente l'uso dell'API Win: saranno comunque necessari per qualsiasi sviluppo serio.

Inoltre, in precedenza abbiamo menzionato le insidie ​​per un'ampia classe di DLL. Nel caso dell'API Win, tutto è molto più semplice, poiché la forma di chiamata di queste funzioni è chiaramente unificata qui. In questo caso, è necessario tenere presenti i seguenti punti principali:

1. Le funzioni API Win32 sono solo funzioni, cioè procedure del tipo Function (c'erano molti Sub nell'API Win16). Tutte queste sono funzioni di tipo Long, quindi le loro descrizioni sono scritte nella forma seguente: Declare Function name ... As Long 'il tipo della funzione _ è definito esplicitamente

   Dichiara il nome della funzione e il "tipo di funzione _ è definito con un suffisso"

   Una chiamata a una funzione API ha il seguente aspetto:

Risultato & = NomeApi & ([ Elenco di argomenti]

1. Molto spesso, il valore restituito da una funzione è un codice di uscita dell'operazione. Inoltre, un valore diverso da zero significa in questo caso un completamento normale, un valore zero significa un errore. Di solito (ma non sempre) è possibile chiarire la natura dell'errore chiamando la funzione GetLastError. La descrizione di questa funzione è simile alla seguente: Declare Function GetLastError & Lib “kernel32” ()

   ATTENZIONE! Quando si lavora in VB, è meglio usare la proprietà LastDLLError dell'oggetto Err per ottenere il valore del codice di errore qualificato, perché a volte VB reimposterà la funzione GetLastError tra la chiamata API e la continuazione dell'esecuzione del programma.

   Puoi interpretare il codice restituito da GelLastError utilizzando le costanti scritte nel file API32.TXT, con nomi che iniziano con il suffisso ERROR_.

   Gli errori più comuni hanno i seguenti codici:

   • ERROR_INVALID_HANDLE = 6 & - handle non valido
   • ERROR_CALL_NOT_IMPLEMENTED = 120 & - chiama in Windows 9x una funzione disponibile solo per Windows NT
   • ERROR_INVALID_PARAMETER = 87 & - valore del parametro non valido

   Tuttavia, molte funzioni restituiscono il valore di alcuni parametri richiesti (ad esempio, OpenFile restituisce un valore del descrittore di file). In tali casi, l'errore viene identificato da un altro valore di ritorno e speciale, il più delle volte 0 o -1.

2. Le API Win32 utilizzano metodi rigorosamente fissi per passare i tipi di dati più semplici. a) ByVal... Finché

   Le variabili lunghe fanno almeno l'80% del passaggio degli argomenti. Nota che l'argomento sempre seguita dalla parola chiave ByVal, che, tra le altre cose, significa che viene eseguito un trasferimento di dati unidirezionale - da un programma VB a una funzione API.

   B) ByVal ... As String

   Anche questo tipo di trasferimento di dati si verifica abbastanza spesso e anche con un argomento sempre ByVal viene applicato. Quando viene chiamata la funzione API, l'indirizzo della stringa viene scritto nello stack, quindi in questo caso è possibile uno scambio di dati bidirezionale. Ci sono diverse insidie ​​da considerare quando si lavora con le stringhe.

   Innanzitutto, la memoria per una stringa è riservata nel programma chiamante, quindi se la funzione API riempie le stringhe, è necessario creare una stringa della dimensione richiesta prima di chiamarla. Ad esempio, la funzione GetWindowsDirectory restituisce il percorso della directory di Windows, che per definizione non deve essere più lungo di 144 caratteri. Di conseguenza, una chiamata a questa funzione dovrebbe essere simile a questa:

   WinPath $ = Spazio $ (144) 'riserva una stringa di _ 144 caratteri Risultato & = GetWindowsDirectory & (WinTath $, 144) _' riempie il buffer 'Risultato & - il numero effettivo di caratteri nel _ nome della directory WinPath $ = Sinistra $ (WinPath, Risultato &)

   Il secondo problema è che quando viene chiamata la funzione API, la stringa originale viene convertita in una rappresentazione interna e quando si esce dalla funzione, viceversa. Se ai tempi di Win16 questa operazione consisteva solo nell'aggiungere uno zero byte alla fine di una stringa, poi con l'avvento di Win32, questa è stata integrata dalla trasformazione della codifica Unicode a doppio byte in ANSI e viceversa. (Questo è stato discusso in dettaglio nell'articolo "Funzionalità di lavorare con variabili stringa in VB", ComputerPress 10'99 e 01'2000). Per ora, notiamo solo che usando la costruzione ByVal ... As String, puoi scambiare stringhe solo con dati di caratteri.

   B) ... Come Qualsiasi

   Ciò significa che alcuni indirizzi del buffer di memoria verranno inseriti nello stack, il cui contenuto verrà interpretato dalla funzione API, ad esempio, a seconda del valore di altri argomenti. Tuttavia, As Any può essere utilizzato solo in un'istruzione Declare: per una chiamata specifica a una funzione, è necessario definire una variabile specifica come argomento.

   D) ... Come UserDefinedType

   Questo design viene spesso utilizzato anche quando è necessario scambiare dati (generalmente in entrambe le direzioni) utilizzando una struttura. In effetti, questa costruzione è una sorta di implementazione concreta del modulo di trasmissione As Any, ma in questo caso la funzione è configurata per una struttura fissa.

   La forma della struttura dati è determinata da una specifica funzione API, ed è responsabilità del programmatore descriverla e riservarla correttamente nel programma chiamante. Questo disegno sempre usato da privo di parole ByVal, ovvero, in questo caso, viene eseguito il trasferimento per riferimento: l'indirizzo della variabile viene scritto nello stack.

Un esempio di chiamata di una funzione API

Illustriamo quanto sopra con un esempio di utilizzo di due funzioni utili per lavorare con i file - lopen e lread, che sono descritte come segue:

Declare Function lopen Lib “kernel32” _ Alias ​​“_lopen” (_ ByVal lpFileName As String, _ ByVal wReadWrite As Long) As Long Declare Function lread Lib “kernel32” _ Alias ​​“_lread” (_ ByVal hFile As Long, lpBuffer As Any, _ ByVal wBytes As Long) As Long

In VB, le loro controparti, in questo caso le esatte, sono le istruzioni Open e Get (per la modalità binaria). Prestiamo immediatamente attenzione all'uso della parola chiave Alias ​​in una dichiarazione di funzione: questo è esattamente il caso in cui non puoi farne a meno. I nomi delle funzioni reali nella libreria iniziano con un carattere di sottolineatura (tipico stile C), che non è consentito in VB.

L'operazione per l'apertura di un file potrebbe essere simile a questa:

Const INVALID_HANDLE_VALUE = -1 'valore del descrittore _ non valido lpFileName $ = “D: \ calc.bas”' nome file wReadWrite & = 2 'modalità lettura-scrittura hFile & = lopen (lpFileName $, wReadWrite &) _' definisce il descrittore del file If hFile & = INVALID_HANDLE_VALUE Quindi _ 'errore di apertura del file' chiarisce il codice di errore CodeError & = Err.LastDllError 'CodeError & = GetLastError _' questa costruzione non funziona End If

Ci sono due punti da notare qui:

• come valore della funzione, otteniamo il valore del descrittore di file. L'errore corrisponde al valore –1;
• proprio in questo caso, la chiamata alla funzione GetLastError non funziona: per ottenere il valore di errore specificato, ci siamo rivolti all'oggetto Err (abbiamo parlato della possibilità di una situazione del genere sopra).

È quindi possibile leggere il contenuto del file, ma questo presuppone che il programmatore debba avere una certa comprensione della sua struttura (proprio come fa quando si lavora con binari arbitrari). In questo caso, una chiamata alla funzione lread potrebbe essere simile a questa:

Dim MyVar As Single wBytes = lread (hFile &, MyVar, Len (MyVar) 'read real number, 4 bytes' wBytes - numero di dati effettivamente letti,' -1 - errore ... Digita MyStruct x As Single i As Integer End Digita Dim MyVar As MyStruct wBytes = lread (hFile &, MyVar, Len (MyVar)) 'leggi struttura dati, 6 byte

Nota ancora: il secondo argomento della funzione viene passato per riferimento, il resto viene passato per valore.

Dim MyVar As String MyVar = Space $ (10) 'prenota una variabile per 10 caratteri wBytes = lread (hFile &, ByVal MyVar, Len (MyVar))' legge una stringa di 10 caratteri

Qui puoi vedere un'importante differenza rispetto all'esempio precedente: la variabile stringa è necessariamente accompagnata dalla parola chiave ByVal.

La lettura del contenuto di un file in un array (per semplicità useremo un array di byte unidimensionale) viene eseguita come segue:

Dim MyArray (da 1 a 10) As Byte wBytes = lread (hFile &, MyArray (1), _ Len (MyArray (1)) * 10) 'legge 10 elementi dell'array

Specificando come argomento il primo elemento dell'array, si passa l'indirizzo dell'inizio dell'area di memoria riservata all'array. Ovviamente, qualsiasi frammento dell'array può essere riempito in questo modo:

WBytes = lread (hFile &, MyArray (4), _ Len (MyArray (1)) * 5) ‘legge gli elementi dell'array da 4 a 8

Suggerimento 5. Usa Alias ​​per Gears e parametri As Any

Qui, sulla base dell'esempio precedente, riveleremo l'essenza del quarto consiglio di Dan Appleman.

Quando si lavora con la funzione lread, ricordare che quando si accede ad essa utilizzando una variabile stringa, è necessario utilizzare la parola chiave ByVal (altrimenti non si può evitare il messaggio di un'operazione illegale). Per sicurezza, puoi creare una descrizione speciale aggiuntiva della stessa funzione per lavorare solo con variabili stringa:

Dichiara la funzione lreadString Lib “kernel32” _ Alias ​​​​“_lread” (_ ByVal hFile As Long, ByVal lpBuffer As String, _ ByVal wBytes As Long) As Long

Quando si lavora con questa descrizione, non è più necessario specificare ByVal quando si accede a:

WBytes = lreadString (hFile &, MyVarString, _ Len (MyVarString)) ‘

Sembrerebbe che la sintassi dell'istruzione Declare ti permetta di creare una descrizione speciale simile per un array:

Dichiara la funzione lreadString Lib “kernel32” Alias ​​​​“_lread” (_ ByVal hFile As Long, lpBuffer () As Byte, _ ByVal wBytes As Long) As Long

Tuttavia, l'appello

WBytes = lreadArray (hFile &, MyArray (), 10)

porta inevitabilmente a un errore fatale del programma.

Questa è una continuazione della conversazione sulle peculiarità dell'elaborazione delle variabili stringa in Visual Basic: VB utilizza una codifica Unicode a doppio byte, Win API - un ANSI a byte singolo (e con il formato accettato in C - con un byte zero al fine). Di conseguenza, quando si utilizzano variabili stringa come argomento, la conversione da Unicode ad ANSI viene sempre eseguita automaticamente quando viene chiamata una funzione API (più precisamente, una funzione DLL) e la conversione inversa viene eseguita al ritorno.

La conclusione è semplice: utilizzando le variabili String è possibile scambiare dati sui caratteri, ma non è possibile utilizzarli per scambiare informazioni binarie arbitrarie (come nel caso delle versioni a 16 bit di VB). In quest'ultimo caso, è meglio utilizzare un array di byte unidimensionale.

Come sai, il tipo String può essere utilizzato per descrivere una struttura personalizzata. A tal proposito si ricorda quanto segue:

• È categoricamente impossibile utilizzare la seguente costruzione per fare riferimento all'API Win: Digitare MyStruct x As Single s As String 'stringa a lunghezza variabile End Type

  Nel caso di una stringa di lunghezza variabile, viene passato come parte della struttura un descrittore di stringa con tutte le conseguenze che ne conseguono sotto forma di errore di esecuzione del programma.

• È possibile utilizzare una stringa a lunghezza fissa come elemento della struttura: Type MyStruct x As Single s As String * 8 'stringa a lunghezza fissa End Type

In questo caso, viene eseguita la corrispondente conversione delle codifiche.

E l'ultima nota: in nessun caso è possibile utilizzare un array di variabili stringa (sia di lunghezza fissa che variabile) quando si chiama una funzione API. In caso contrario, sarà garantita l'apparenza di una "operazione illegale".

È molto probabile che ti imbatterai in una situazione in cui devi scrivere le tue funzioni DLL. La necessità di ciò apparirà inevitabilmente se si utilizza la tecnologia di programmazione mista: l'uso di due o più linguaggi di programmazione per implementare un'applicazione.

Si noti a questo proposito che la programmazione mista è abbastanza comune per un'applicazione abbastanza complessa. In effetti, ogni linguaggio (più precisamente, un sistema di programmazione basato su linguaggio) ha i suoi punti di forza e di debolezza, quindi è abbastanza logico utilizzare i vantaggi di strumenti diversi per risolvere problemi diversi. Ad esempio, VB - per creare un'interfaccia utente, C - per un accesso efficiente alle risorse di sistema, Fortran - per implementare algoritmi numerici.

L'opinione dell'autore è che qualsiasi programmazione seria richiede che lo sviluppatore possieda almeno due strumenti. Naturalmente, nelle condizioni moderne di una chiara divisione del lavoro, è molto difficile essere un eccellente esperto anche in due sistemi, quindi lo schema "lingue principali e ausiliarie" è più logico. L'idea qui è che anche una conoscenza superficiale della lingua "ausiliaria" (scrivendo procedure abbastanza semplici) può aumentare notevolmente l'efficacia della lingua "principale". Si noti che la conoscenza di VB, almeno come ausiliaria, è oggi un requisito quasi obbligatorio per un programmatore professionista. A proposito, ai tempi del DOS per qualsiasi programmatore, incluso Basic, era altamente desiderabile conoscere le basi di Assembler.

In un modo o nell'altro, ma anche nelle condizioni del lavoro di gruppo, quando ogni programmatore è impegnato nella propria attività specifica, tutti i partecipanti al progetto dovrebbero avere un'idea delle caratteristiche dell'interfaccia procedurale in diverse lingue. E sapere che molti sistemi di programmazione (incluso VB), oltre all'interfaccia predefinita, consentono di utilizzare altri metodi estesi di riferimento alle procedure, che consentono di adattare l'interfaccia a un'altra lingua.

Quando si studia l'interfaccia interprocedurale, è necessario prestare attenzione alle seguenti possibili insidie:

• Lingue diverse possono utilizzare convenzioni diverse su come scrivere gli identificatori. Ad esempio, viene spesso utilizzato un carattere di sottolineatura all'inizio del nome di una procedura, che è vietato in VB. Questo problema è facilmente risolvibile utilizzando la parola chiave Alias ​​nell'istruzione Declare (vedi esempio suggerimento 2.3).
• È possibile utilizzare una sequenza diversa di scrittura degli argomenti passati nello stack. Ad esempio, ai tempi del DOS (onestamente non so come appare ora in Windows), C ha scritto argomenti dalla fine dell'elenco, altri linguaggi (Fortran, Pascal, Basic) - dall'inizio.
• Per impostazione predefinita, vengono utilizzati diversi principi di passaggio dei parametri, per riferimento o per valore.
• Vari principi di memorizzazione delle variabili stringa. Ad esempio, in C (così come in Fortran e Pascal) la lunghezza di una stringa è definita da uno zero byte alla sua fine, mentre in Basic la lunghezza è scritta esplicitamente nel descrittore di stringa. Naturalmente, è necessario tenere presente la possibilità di utilizzare diverse codifiche dei caratteri.
• Quando si trasferiscono array multidimensionali, ricordare che esistono varie opzioni per convertire strutture multidimensionali in unidimensionali (a partire dal primo indice o dall'ultimo, in relazione agli array bidimensionali - "per righe" o "per colonne").

Tenendo conto di tutto ciò, si possono formulare le seguenti raccomandazioni:

• Utilizzare i modi più semplici e comprovati per passare argomenti alle funzioni DLL. Gli standard adottati per l'API Win sono buoni esempi.
• Non passare in nessun caso array di variabili stringa.
• Utilizzare un passaggio molto attento di semplici variabili stringa e array multidimensionali.
• Assicurati di controllare in modo speciale la funzionalità del meccanismo per il passaggio di argomenti da e verso la procedura chiamata. Scrivi un test personalizzato per testare la trasmissione dei dati. Verificare separatamente che ogni argomento sia passato correttamente. Ad esempio, se hai una procedura con più argomenti, controlla prima che ogni parametro sia passato correttamente per una variante con un argomento e solo dopo per l'intero elenco.

Ma cosa succede se la funzione DLL è già stata scritta, ad esempio, in Fortran, ma la sua interfaccia di input non si adatta bene agli standard VB di cui sopra? Ci sono due consigli da dare qui. Per prima cosa, scrivi una funzione DLL di prova e usala per cercare di trovare la chiamata giusta dal programma VB per tentativi ed errori. Secondo: scrivere una procedura dell'adattatore nello stesso Fortran che fornirebbe una semplice interfaccia tra VB e una funzione DLL con la conversione di strutture dati semplici in strutture complesse (ad esempio, convertendo un array di byte multidimensionale in un array di stringhe).

Quindi: usa le funzioni DLL. Ma stai attento...

ComputerPress 9 "2000

L'API definisce la funzionalità fornita dal programma (modulo, libreria), mentre l'API consente di astrarre da come viene implementata esattamente questa funzionalità.

Se un programma (modulo, libreria) è considerato come una scatola nera, allora l'API è un insieme di "manopole" disponibili per l'utente di questa scatola, che può ruotare e tirare.

I componenti software interagiscono tra loro tramite API. In questo caso, i componenti di solito formano una gerarchia: i componenti di alto livello utilizzano l'API dei componenti di basso livello e quelli, a loro volta, utilizzano l'API di componenti anche di livello inferiore.

Secondo questo principio, vengono costruiti i protocolli di trasferimento dei dati. Il protocollo Internet standard (modello di rete OSI) contiene 7 livelli (dal livello fisico della trasmissione dei pacchetti di bit al livello dei protocolli applicativi come HTTP e IMAP). Ciascun livello sfrutta le funzionalità del livello di trasferimento dati precedente e, a sua volta, fornisce la funzionalità desiderata al livello successivo.

È importante notare che il concetto di protocollo è vicino nel significato al concetto di API. Entrambi sono astrazioni di funzionalità, solo nel primo caso stiamo parlando di trasferimento di dati e nel secondo - di costruzione di applicazioni per computer.

L'API della libreria di funzioni e classi include una descrizione firme e semantica delle funzioni.

L'Application Programming Interface (API) è un'interfaccia di programmazione per l'interazione tra sistemi che consente:

• Accedi ai servizi aziendali aziendali
• Scambiare informazioni tra sistemi e applicazioni
• Semplifica le interazioni tra aziende, partner, sviluppatori e clienti

Strategia API aperta

La strategia API include:

• Sviluppo di prodotti aziendali basati su API esistenti
• Fornire servizi interni agli sviluppatori
• Modelli di monetizzazione API per costruire interazioni multicanale e aumentare i profitti

L'implementazione del concetto Open API aiuta a trasformare un'azienda, integrarla in un ecosistema di progetti flessibile di attori di mercato, creare le condizioni per la generazione costante di nuove idee e la formazione di valore aggiuntivo nella gestione degli array di dati aziendali.

Il mercato delle soluzioni di integrazione si sta sviluppando nel contesto dell'evoluzione delle API - da EDI e SOAP al Web 2.0, che ha dato inizio all'era delle API pubbliche. Il numero di tali interfacce nei prossimi 3 anni può crescere di oltre 50 volte e raggiungere 1 milione. Questo è dovuto alla multicanalità: con loro devono cambiare i canali di interazione con i clienti. La continua crescita del numero di consumatori e del volume di dati ha portato all'emergere dell'economia API, che aiuta a creare modelli di business innovativi per l'utilizzo di risorse e servizi aziendali basati su interfacce aperte.

Firma della funzione

Firma della funzione- parte di una dichiarazione di funzione generica che consente alle emittenti di identificare la funzione tra le altre. Diversi linguaggi di programmazione hanno idee diverse sulla firma di una funzione, che è anche strettamente correlata alle possibilità di sovraccarico delle funzioni in questi linguaggi.

A volte distinguere firma di chiamata e firma di implementazione funzioni. La firma della chiamata è solitamente costruita dalla struttura sintattica di una chiamata di funzione, tenendo conto della firma dell'ambito della funzione data, del nome della funzione, della sequenza dei tipi effettivi degli argomenti nella chiamata e del tipo di risultato. La firma dell'implementazione di solito include alcuni elementi della costruzione sintattica di una dichiarazione di funzione: l'identificatore dell'ambito della funzione, il suo nome e la sequenza dei tipi di argomento formali.

Ad esempio, nel linguaggio di programmazione C++, una funzione semplice è riconosciuta inequivocabilmente dal compilatore dal suo nome e dalla sequenza dei tipi dei suoi argomenti, che costituisce la firma della funzione in questo linguaggio. Se la funzione è un metodo di una classe, nella firma verrà incluso anche il nome della classe.

Va inoltre notato che un programmatore ha spesso a disposizione diverse API che consentono di ottenere lo stesso risultato. Tuttavia, ogni API viene solitamente implementata utilizzando l'API dei componenti software di un livello di astrazione inferiore.

Ad esempio: per vedere la riga "Hello, world!" tutto ciò che devi fare è creare un documento HTML con un'intestazione minima e un corpo semplice contenente la stringa data. Cosa succede quando il browser apre questo documento? Il programma browser trasferirà il nome del file (o un descrittore di file già aperto) alla libreria che elabora i documenti HTML, la quale, a sua volta, utilizzando l'API del sistema operativo, leggerà questo file e ne comprenderà il dispositivo, chiamerà operazioni come "Cancella la finestra", "scrivi con il carattere selezionato Hello, world!" this".

Allo stesso tempo, praticamente a ciascuno dei livelli, esistono effettivamente diverse possibili API alternative. Ad esempio: potremmo scrivere il documento originale non in HTML, ma in LaTeX, per la visualizzazione potremmo usare qualsiasi browser. Browser diversi generalmente utilizzano librerie HTML diverse e, inoltre, possono essere (in generale) compilati utilizzando diverse librerie primitive e su diversi sistemi operativi.

Le principali sfide dei sistemi API a strati esistenti sono quindi:

• La complessità di trasferire il codice del programma da un sistema API a un altro (ad esempio, quando si cambia il sistema operativo);
• Perdita di funzionalità quando si passa da un livello inferiore a uno superiore. In parole povere, ogni "livello" API viene creato per facilitare alcune operazioni standard. Ma allo stesso tempo, diventa davvero difficile o diventa fondamentalmente impossibile eseguire alcune altre operazioni fornite da un livello API inferiore.

Tipi di API di base

API interna

• L'accesso all'API è fornito solo agli sviluppatori interni
• Applicazioni destinate ai dipendenti dell'impresa

Driver aziendali:

• Coerenza di sviluppo
• Costi ridotti
• Migliorare l'efficienza dello sviluppo

API dei partner

• Le API sono disponibili solo per un numero limitato di partner commerciali
• Le applicazioni sono destinate ai consumatori finali e agli utenti aziendali

Driver aziendali:

• Automazione del processo di sviluppo
• Sviluppo di partnership
• Ottimizzazione del processo di interazione con i partner

API pubbliche

L'accesso è fornito a qualsiasi sviluppatore esterno Le applicazioni sono destinate agli utenti finali

Driver aziendali:

• Sviluppo di nuovi servizi
• Sviluppo dell'ecosistema
• Interazione multicanale

Le API più famose

API dei sistemi operativi

API GUI

• Direct3D (parte di DirectX)
• DirectDraw (parte di DirectX)

Puoi provare gioia e frustrazione quando lavori con un'API. Da un lato, interagendo con altre applicazioni, puoi aumentare notevolmente la portata del pubblico e l'effetto "wow" della tua applicazione. Dall'altro, ciò include la lettura di una tonnellata di documentazione, l'apprendimento delle strategie di autenticazione e l'analisi di messaggi di errore non informativi (o addirittura mancanti).

Prima di tutto, se ancora non capisci completamente cosa sia un'API (Application Programming Interface), leggi la spiegazione di Skillcrush e poi la prima parte di questo articolo per recuperare il ritardo.

"API" è un concetto incredibilmente ampio: ogni volta che la tua applicazione "parla" con un'altra applicazione, avviene tramite un'API. Anche i componenti all'interno della tua applicazione, come le diverse parti di Rails, comunicano tra loro tramite API. Sono sotto-applicazioni più o meno indipendenti che veicolano i dati di cui ciascuno ha bisogno per svolgere i propri compiti specifici. Nel mondo delle applicazioni, tutto è API!

Quando crei applicazioni con funzionalità front-end più dinamiche (sia applicazioni Javascript a pagina singola che applicazioni semplici con chiamate AJAX separate), comunicheranno con il backend Rails tramite la tua API, che in realtà è solo un paio di righe di codice in più. dicendo ai tuoi controller come servire JSON o XML invece di HTML.

In questo tutorial imparerai come creare la tua API. Nelle lezioni successive, evidenzieremo come interagire con le API di altre applicazioni. Le lezioni dovrebbero essere un buon trampolino di lancio per l'apprendimento di questo argomento, ma è improbabile che siano in grado di coprire completamente tutti i casi. La maggior parte del lavoro con le API è sapere come leggere la loro documentazione e capire cosa vogliono da te.

Punti a cui pensare

Rivedi le domande e vedi se conosci le risposte. Controlla di nuovo te stesso dopo aver completato l'attività.

• In che modo Rails comprende il tipo di file che ti aspetti in risposta quando effettui una richiesta HTTP.
• Qual è lo scopo del metodo #respond_to?
• Come si restituisce un oggetto User mentre si specificano gli attributi che non si desidera includere in quell'oggetto (ovvero, non si può semplicemente restituire User.first)?
• Quali sono i 2 passaggi dietro le quinte del metodo #to_json?
• Come faccio a dire all'azione del controller di visualizzare solo il messaggio di errore?
• Come creo il mio messaggio di errore?
• Perché non puoi utilizzare metodi di autenticazione del controller basati sulla sessione se desideri consentire connessioni programmatiche alla tua API?
• Che cos'è l'architettura orientata ai servizi?

Nozioni di base sull'API

La tua applicazione Rails è in realtà già un'API, anche se potresti non pensarla come un'API. Anche il browser web eseguito dai tuoi utenti è un programma, quindi in realtà effettua una richiesta API alla tua applicazione Rails quando l'utente apre una nuova pagina. La pensavamo in questo modo perché il rendering dei modelli HTML è un'attività così comune che abbiamo semplicemente codificato questa funzionalità nei nostri programmi server come un tipo di risposta standard e consideriamo tutto il resto insolito.

Tuttavia, spesso si desidera effettuare una richiesta che non richieda di affrontare tutti i grattacapi dell'utilizzo del browser. Potrebbe non interessarti la struttura della pagina (HTML), ma in cambio desideri dati puliti. Supponiamo che tu voglia ottenere un elenco di tutti gli utenti. Puoi richiedere qualcosa come http://yourapplication.com/users, che molto probabilmente attiverà un'azione #index e renderà un elenco di tutti gli utenti nell'applicazione.

Ma perché preoccuparsi di tutte queste informazioni inutili quando tutto ciò che vuoi è ottenere un elenco di utenti? L'opzione più semplice sarebbe inviare una richiesta allo stesso URL, specificando in cambio un'aspettativa di una risposta JSON o XML. Se imposti correttamente il tuo controller Rails, otterrai un semplice oggetto array JSON contenente tutti gli utenti. Perfettamente!

Lo stesso principio si applica quando comunichi con un'API esterna. Supponiamo che tu voglia ricevere i "tweet" recenti di un utente da Twitter. Tutto quello che devi fare è dire alla tua applicazione Rails come interagire con l'API di Twitter (cioè autenticarsi), inviare la richiesta ed elaborare il set di tweet che vengono restituiti.

Creazione API

Potresti voler rendere la tua applicazione Rails un puro backend API per le pagine Web front-end, o potresti semplicemente voler imparare a inviare JSON quando il front-end lo richiede. Questa sezione non tratterà come creare API RESTful complete con funzionalità di autenticazione. Questa è una semplice introduzione al trattamento della tua applicazione come un'API.

Le basi

Se vuoi che la tua applicazione Rails restituisca JSON invece di HTML, devi dire al tuo controller di farlo. La cosa bella è che la stessa azione del controller può restituire tipi diversi a seconda che l'utente effettui una richiesta regolare dal browser o acceda all'API tramite la riga di comando. Ciò determina il tipo di richiesta effettuata in base all'estensione del file richiesto, ad esempio example.xml o example.json.

Puoi controllare cosa "pensa" Rails sul tipo di file che ti aspetti controllando il log del server:

Avviato GET "/posts/new" per 127.0.0.1 at 2013-12-02 15:21:08 -0800 Elaborazione da parte di PostsController # nuovo come HTML

La prima riga ti dice quale URL è stato richiesto e la seconda ti dice dove è stato diretto e come Rails lo gestisce. Se stavi usando l'estensione .json, sarebbe simile a questo:

Avviato GET "/posts.json" per 127.0.0.1 at 2013-12-04 12:02:01 -0800 Elaborazione da PostsController # index come JSON

Se hai un'applicazione di prova in esecuzione, prova a richiedere URL diversi. Se il tuo controller non sa come gestirli, potresti ricevere un errore, ma dovresti comunque vedere cosa capisce Rails dalle tue richieste.

Rendering JSON o XML

Quando decidi di voler rispondere alle richieste con JSON o XML, devi dire al controller di eseguire il rendering di JSON o XML anziché HTML. Un modo per farlo è usare il metodo #respond_to:

Classe UsersController< ApplicationController def index @users = User.all respond_to do |format| format.html # index.html.erb format.xml { render xml: @users } format.json { render json: @users } end end end

In questo caso, #respond_to passa un oggetto formato al blocco, al quale è possibile allegare una chiamata di rendering appropriata. Se non fai nulla, l'html verrà renderizzato usando il template Rails standard (app/views/index.html.erb in questo esempio).

La funzione #render è abbastanza intelligente da capire come eseguire il rendering di un'ampia varietà di formati. Quando gli passi la: chiave json, chiamerà #to_json sul valore, in questo esempio @users. Questo convertirà i tuoi oggetti Ruby in stringhe JSON, che verranno passate all'applicazione richiedente.

In questo modo ottieni la tua API. Naturalmente, la creazione di un'API può essere un po' più complessa se si desidera eseguire alcune cose insolite, ma tutto è mantenuto sulle basi.

Specificare gli attributi di ritorno

Supponiamo che tu voglia assicurarti di non restituire l'indirizzo email dell'utente insieme all'oggetto User. In questo caso, vorrai cambiare gli attributi che verranno restituiti, modificando ciò che fa il metodo #to_json.

In precedenza, avresti semplicemente sovrascritto il metodo #to_json con la tua versione, ma ora non ne hai bisogno - infatti, sovrascriverai invece il metodo #as_json. Il metodo #as_json è usato nel metodo #to_json, quindi modificandolo implicitamente cambia il risultato #to_json, ma in un modo piuttosto specifico.

#to_json fa 2 cose: esegue #as_json e ottiene un hash di attributi che verranno resi in JSON. Quindi esegue il rendering su JSON utilizzando ActiveSupport :: json.encode. Quindi, modificando #as_json, sei più specifico sulla parte del metodo #to_json che desideri effettivamente modificare.

Nel nostro caso, lo facciamo modificando #as_json nel nostro modello per restituire solo gli attributi di cui abbiamo bisogno:

# app/modelli/user.rb classe Utente< ActiveRecord::Base # Вариант 1: Полное переопределение метода #as_json def as_json(options={}) { :name =>self.name) # NON includere il campo email end # Opzione 2: utilizzare il metodo standard #as_json def as_json (options = ()) super (solo: [: name]) end end

Quindi, nel nostro controller, dobbiamo solo eseguire il rendering del JSON come al solito (nell'esempio seguente, JSON verrà sempre restituito, indipendentemente dal fatto che sia stata inviata o meno una richiesta HTML):

# app/controller/users_controller.rb class UsersController< ApplicationController def index render json: User.all end end

Nota che non devi chiamare #to_json da solo quando usi #render: lo fa per te.

A volte Heroku potrebbe richiedere passaggi aggiuntivi per visualizzare correttamente le pagine di errore. Guarda. Potrebbe essere necessario rimuovere prima le pagine statiche dall'app/dalla directory pubblica.

Sicurezza dall'esterno

Supponiamo che tu voglia consentire l'accesso all'API solo se l'utente ha effettuato l'accesso. La tua autenticazione esistente nel controller fa già il lavoro: assicurati solo di avere il corretto #before_action impostato (come before_action: require_login). Potrebbe essere necessaria la funzionalità quando sia gli utenti che hanno effettuato l'accesso che quelli che non hanno effettuato l'accesso possono visualizzare la pagina, ma tutti dovrebbero vedere dati diversi. Non vuoi che gli utenti non registrati siano in grado di effettuare richieste API per ottenere dati sensibili. Allo stesso modo, non si desidera consentire a utenti non autorizzati di visitare determinate pagine HTML.

Se desideri elaborare le richieste da un'applicazione non browser (come la riga di comando), non puoi fare affidamento sui cookie del browser per l'autenticazione. Questo è il motivo per cui la maggior parte delle API utilizza i propri token come parte del processo di autenticazione. Parleremo un po' di più dei token nel prossimo tutorial.

Prossimi passi

Ora hai le competenze per utilizzare la tua applicazione Rails per servire non solo HTML, ma qualsiasi altro formato. Se vuoi andare oltre e consentire ad altri sviluppatori di creare qualcosa utilizzando la tua piattaforma (ad esempio, in modo che possano effettuare richieste programmatiche invece di autenticarsi come utente), dovrai rendere il tuo sistema API molto più sicuro. Non tratteremo tutto questo qui, ma dai un'occhiata alle seguenti risorse:

• L'articolo Building Awesome Rails APIs descrive molti dei migliori approcci per passare da un'app giocattolo a standard API industriali.

Architettura orientata ai servizi

È tempo di introdurre un approccio architetturale chiamato Service-Oriented Architecture (SOA). L'idea di base è che la tua applicazione sarà composta da molti servizi come il sistema di pagamento, la registrazione dell'utente, il modulo di raccomandazione, ecc. Invece di creare tutto questo all'interno di un'applicazione principale, dividi i sottosistemi in parti completamente indipendenti che interagiscono tra loro utilizzando API interne.

Questo è buono per molte ragioni. Poiché a ogni parte della tua applicazione non interessa come funzionano le altre parti e sa solo come richiedere i dati tramite la loro API, puoi apportare modifiche significative al codice del servizio e il resto dell'applicazione funzionerà come prima. Puoi sostituire completamente un servizio con un altro e finché interagisce utilizzando gli stessi metodi API, andrà molto bene. Puoi utilizzare API esterne come parte della tua applicazione (come i sistemi di pagamento) invece di scriverne di tue. Puoi creare un'applicazione PHP che interagisce con un'applicazione Python che interagisce con un'applicazione Rails e tutto funzionerà, perché comunicano tra loro utilizzando l'API.

In genere è una buona idea cercare di rendere ogni parte dell'applicazione il più indipendente possibile. Il concetto di SOA ti incoraggia a pensare in termini di esattamente quali metodi vuoi esporre ad altre parti della tua applicazione e migliora anche il tuo codice. Inoltre, assumendo che ogni componente principale della tua applicazione sia indipendente, puoi anche isolare i problemi molto più facilmente e gestire gli errori in modo più significativo.

Usare un'architettura orientata ai servizi per un'intera applicazione è come scomporre uno script Ruby gigante e complesso in classi e metodi eleganti, solo su una scala più ampia.

Uno dei casi più noti di transizione verso un'architettura orientata ai servizi è Amazon.com. Un giorno del 2002, Jeff Bezos dichiarò senza mezzi termini che tutti i gruppi di lavoro dovevano andare alla SOA o essere licenziati. famigerato post sul blog un dipendente di Google, destinato a scopi interni, ma reso pubblico accidentalmente, ha parlato della potenza di Amazon nell'utilizzo della SOA. Questa è una lettura eccellente, quindi assicurati di apprezzarla, ma le tesi principali della lettera di Bezos sono riportate nelle seguenti citazioni dal post:

1) Tutti i team d'ora in poi forniscono i propri dati e funzionalità tramite interfacce di servizio.

2) I team devono comunicare tra loro attraverso queste interfacce.

3) Sono vietate altre forme di comunicazione tra processi: nessun collegamento diretto, nessuna lettura diretta dei dati di un altro comando, nessun modello di memoria condivisa, nessuna backdoor e simili. L'unico metodo di comunicazione consentito consiste nell'accedere all'interfaccia dei servizi sulla rete.

4) Non importa quale tecnologia usano. HTTP, Corba, Pubsub, protocolli proprietari - nessuna differenza. A Bezos non interessa.

5) Tutte le interfacce di servizio, nessuna esclusa, devono essere inizialmente progettate con capacità di controllo dall'esterno. Cioè, il team deve pianificare e progettare per essere in grado di fornire un'interfaccia agli sviluppatori esterni all'azienda. Non ci sono eccezioni.

6) Chi ha ignorato questi requisiti sarà licenziato.

SOA è una cosa seria. Ci sono indubbiamente molti problemi che si presentano quando lo si utilizza - dai un'occhiata a questo post su Amazon "lezioni apprese" - ma ha un numero incredibile di vantaggi.

Probabilmente non sarai troppo preoccupato per la SOA mentre crei applicazioni "giocattolo" per te stesso, ma questa domanda ti sorgerà sicuramente quando inizi a lavorare per un'azienda IT, quindi conoscerla è una buona pratica.

Il tuo obiettivo

1. Leggi la sezione 7 della Rails Guide to Controllers per informazioni sul rendering di JSON e XML.
2. Sono facoltativi (perché vanno un po' oltre quello che abbiamo attualmente), ma se sei curioso, dai un'occhiata ai Railscast nella sezione Risorse aggiuntive in fondo al tutorial per saperne di più sui vantaggi dell'API.

Conclusione

Lavoreremo più a stretto contatto con la tua applicazione come API durante il corso Javascript. In questo corso creerai diverse applicazioni full stack che utilizzano chiamate AJAX per una migliore interfaccia utente, che di fatto implica il rendering di dati XML o JSON invece di una pagina HTML completa. Successivamente, creerai diverse applicazioni Javascript a pagina singola che si basano sull'API fornita dalla tua applicazione Rails per ottenere tutti i dati di cui ha bisogno dal database e che altrimenti verranno eseguite sul lato client (nel browser).

Il modo migliore per comprendere l'API è creare e interagire con essa, cosa su cui ci concentreremo nei nostri progetti.

In questo post, ho cercato di raccogliere informazioni che potrebbero essere utili ai tester che vogliono sapere cos'è un'API. Spero che le persone esperte nei test API troveranno qualcosa di utile per se stesse. Bene, o almeno aiutarti a trovare errori nel mio articolo :)
Cos'è l'API

API (Application Programming Interface) è un insieme di classi, procedure, funzioni, strutture e costanti già pronte fornite da un'applicazione (libreria, servizio) per l'utilizzo in prodotti software esterni (Wikipedia).

Con parole nostre, l'API ci offre l'opportunità di utilizzare il lavoro di altre persone per i nostri scopi. Ho incontrato per la prima volta l'API utilizzando l'API di Windows come esempio. Questo è un insieme di funzioni che possono essere utilizzate da qualsiasi applicazione in esecuzione su un determinato sistema operativo. Ad esempio, può utilizzare funzioni standard per eseguire il rendering dell'interfaccia.

Le API moderne spesso assumono la forma di servizi Web che forniscono informazioni agli utenti (sia umani che altri servizi Web). Solitamente, la procedura di scambio delle informazioni e il formato di trasferimento dei dati sono strutturati in modo che entrambe le parti sappiano interagire tra loro.

Sul sito https://dev.hh.ru/ (più precisamente https://github.com/hhru/api/blob/master/docs/general.md) è possibile trovare una descrizione di come funzionano i client API HeadHunter e servizi interagiscono tra loro. Ad esempio, una citazione dal sito:

• Tutte le API funzionano su protocollo HTTPS.
• L'autorizzazione viene eseguita utilizzando il protocollo OAuth2.
• Tutti i dati sono disponibili solo in formato JSON.
• URL di base - https://api.hh.ru/
• Le date sono formattate secondo ISO 8601: AAAA-MM-GGThh: mm: ss ± hhmm

Puoi leggere l'API HH per un buon esempio di documentazione personalizzata.

Formati di trasferimento dati

Esistono molti formati di dati che gli utenti utilizzano per interagire con l'API. Ad esempio, il noto XML. Oppure JSON è un formato leggero e semplice che assomiglia a:

("id": "0001", "tipo": "ciambella", "nome": "Torta", "immagine": ("url": "immagini / 0001.jpg", "larghezza": 200, "altezza ": 200)) NS o ss I link sottostanti puoi vedere le risposte provenienti da MediaWikiAPI , in diversi formati :

JSON:https://en.wikipedia.org/w/api.php?action=query&titles=Albert%20Einstein&prop=info&format=jsonfm
XML: https://en.wikipedia.org/w/api.php?action=query&titles=Albert%20Einstein&prop=info&format=xmlfm
PHP: https://en.wikipedia.org/w/api.php?action=query&titles=Albert%20Einstein&prop=info&format=php ( con attenzione, accadrà con altalena file)

Http r lagols

Generalmente NS Quando si accede all'API webusando ci sono richieste HTTP . Ecco perchèDevo dire almeno brevemente su metodi standard, che può essere contenuto in Richiesta HTTP . Questi metodi chiamati anche verbi HTTP :

• OTTENERE. Probabilmente il tipo più popolare richiesta. Utilizzato per ricevere o leggere dati.
• METTERE. Costume n Oh e spo utilizzato per aggiornare la risorsa .
• INVIARE. Solitamente utilizzato per creare una nuova risorsa.
• ELIMINA. Elimina i dati.
• Altro

Se vogliamo ottenere informazioni su una risorsa,il cui URI http://www.example.com/customers/12345 , possiamo inviare una richiesta:
OTTIENI http://www.example.com/customers/12345

Se vogliamo aggiornare una risorsa - possiamo inviare una richiesta PUT:
METTI http://www.example.com/customers/12345/orders/98765

Le richieste GET regolari possono essere inviate dal browser web. Per inviare altri tipi di richieste, potrebbero essere necessari linguaggi di scripting o strumenti speciali (maggiori informazioni di seguito).

Informazioni su HTTP i metodi possono essere letti in modo più dettagliato a su W iki.

HTTP agli odi di risposte

Il server può inviare codici diversi in risposta alle richieste dell'utente. Questi possono essere codici di errore o semplicemente codici che informano gli utenti sullo stato del server. Una descrizione dettagliata può essere trovata, ancora una volta, sul wiki.

I codici più famosi sono 4xx (problemi lato client) e 5xx (problemi lato server). Gli stessi sviluppatori dell'API decidono quali codici restituire in una determinata situazione. Ad esempio, l'API del sito Web Odnoklassniki restituisce codici, la cui descrizione è disponibile su https://apiok.ru/wiki/pages/viewpage.action?pageId=77824003.

Inoltre, ti consiglio di ascoltare la canzone Request-response - è semplice e chiaro sui codici restituiti nelle richieste HTTP (fai attenzione, repchik :)).

API REST

REST API è l'ideologia del post brulicante API, che sta perTrasferimento di Stato di rappresentanza API. Si basa sui seguenti principi formulati dal suo creatore di Roy Fielding:

1. Architettura client-server
2. Server senza stato
3. Possibilità di memorizzazione nella cache
4. Struttura multistrato
5. Interfaccia unificata
6. Codice su richiesta

Non entro nei dettagli, posso consigliare chi vuole leggere sull'argomento