Sandbox

čelik, mink, govedina, papir 26. novembar 2012. u 13:59

Šta je API

Pozdrav!
U ovom članku ćemo pogledati šta je API, gdje, kako i za šta se koristi. Također ćemo pogledati kako se API može primijeniti u vašem web razvoju i kako može pojednostaviti život web programera.

Dakle, počnimo s definicijom. API (Application Programming Interface) je programski interfejs, interfejs za kreiranje aplikacija. U razumljivijem jeziku, API je gotov kod koji pojednostavljuje život programera. API je kreiran tako da programer zaista može olakšati zadatak pisanja aplikacije koristeći gotov kod (na primjer, funkcije). Dobro poznati jQuery napisan u JavaScript-u je takođe vrsta API-ja. Ako uzmemo u obzir ovaj konkretni primjer, onda jQuery znatno olakšava pisanje koda. Ono što bi se moglo uraditi u 30 redova sa običnim JavaScript sredstvima je napisano kroz jQuery u 5-6. Ako pogledamo API općenito, onda možete pronaći mnogo servisa koji predstavljaju rješenja za razvoj. Danas je najpoznatiji servis code.google.com koji nudi pedesetak različitih API-ja! Ovo je sučelje za kreiranje Android aplikacija, i razni API-ji za rad sa AJAX-om, te razni API-ji aplikacija koje možete lako prilagoditi svojim željama.

Uostalom, ima li smisla pisati kod vlastitim rukama? Zašto raditi na onome što je već stvoreno? Ima li smisla odustati od besplatnih rješenja (a zapravo i besplatne pomoći) u web razvoju? Ako ste na sva ova pitanja odgovorili „NE“, pretpostavite da razumijete suštinu API-ja.

Ali takođe želim da rezervišem. Programeri početnici NE bi trebali koristiti polugotova rješenja, jer se u budućnosti neće nositi sa stvarnim zadatkom. Stoga, ako ste početnik web programer, nemojte koristiti poluproizvode! Naučite razmišljati svojom glavom, izgradite različite algoritme da biste razumjeli suštinu programiranja. Takođe kažem, već se obraćajući svima, da API nisu gotova rješenja, to je okruženje, interfejs za kreiranje vaših projekata. Ne jedete smrznute hamburgere iz prodavnice, zar ne? Prvo ih ispržiš, zar ne? Ova analogija je vrlo jasna o suštini API-ja.

Generalno, rekao sam vam šta je API, gde i kako se koristi, najvažnije za šta. Želim vam ugodno učenje web programiranja i razumijevanje njegovih sve većih dubina!

Tagovi: api

Ovaj članak nije podložan komentarisanju, jer njegov autor još nije punopravni član zajednice. Autora ćete moći kontaktirati tek nakon što primi

Windows API - skup funkcija operativnog sistema

Skraćenica API mnogim programerima početnicima izgleda vrlo misteriozno, pa čak i zastrašujuće. U stvari, sučelje za programiranje aplikacije (API) je samo neki gotov skup funkcija koje programeri aplikacija mogu koristiti. Generalno, ovaj koncept je ekvivalentan onome što se nekada zvalo biblioteka rutina. Međutim, API se obično odnosi na posebnu kategoriju takvih biblioteka.

Tokom razvoja gotovo svake dovoljno složene aplikacije (MyAppication) za krajnjeg korisnika, formira se skup specifičnih internih funkcija koje se koriste za implementaciju ovog konkretnog programa, a koji se naziva MyApplication API. Međutim, često se ispostavi da se ove funkcije mogu efikasno koristiti za kreiranje drugih aplikacija, uključujući i druge programere. U tom slučaju, autori se, na osnovu strategije promocije svog proizvoda, moraju odlučiti na pitanje: otvaraju li pristup ovom setu vanjskim korisnicima ili ne? Ako je odgovor potvrdan u opisu softverskog paketa, izraz se pojavljuje kao pozitivna karakteristika: "Kit uključuje otvoreni skup API funkcija" (ali ponekad za dodatni novac).

Dakle, najčešće API znači skup funkcija koje su dio jedne aplikacije, ali su istovremeno dostupne za korištenje u drugim programima. Na primjer, Excel, pored sučelja za krajnjeg korisnika, ima skup Excel API funkcija koje se mogu koristiti, posebno, prilikom kreiranja aplikacija pomoću VB.

U skladu s tim, Windows API je skup funkcija koji je dio samog operativnog sistema i istovremeno je dostupan za bilo koju drugu aplikaciju, uključujući i one napisane pomoću VB-a. U tom smislu je sasvim opravdana analogija sa BIOS/DOS sistemom prekida, koji je zapravo DOS API.

Razlika je u tome što je sastav Windows API funkcija, s jedne strane, mnogo širi nego u DOS-u, s druge strane, ne uključuje mnoge alate za direktnu kontrolu računarskih resursa koji su bili dostupni programeri u prethodnom OS. Osim toga, Windows API-ju se pristupa korištenjem običnih proceduralnih poziva, a pozivi DOS funkcija se vrše preko posebne strojne naredbe procesora koja se zove Interrupt.

Zašto vam treba Win API za VB programere

Unatoč činjenici da VB ima ogroman izbor funkcija, u procesu manje ili više ozbiljnog razvoja, ispostavlja se da njihove sposobnosti često nisu dovoljne za rješavanje potrebnih zadataka. Istovremeno, programeri početnici često počinju da se žale na nedostatke VB-a i razmišljaju o promjeni alata, ne sluteći da na njihovom računalu postoji ogroman skup alata i samo ih trebate moći koristiti.

Nakon upoznavanja sa Win API-jem, otkriva se da mnoge ugrađene VB funkcije nisu ništa drugo do pozivi odgovarajućim sistemskim procedurama, već samo implementirane u obliku sintakse ovog jezika. Imajući to na umu, potreba za korištenjem API-ja određena je sljedećim opcijama:

1. API funkcije koje su u potpunosti implementirane kao ugrađene VB funkcije. Ipak, ponekad je u ovom slučaju korisno i preći na korištenje API-ja, jer to ponekad može značajno povećati performanse (posebno zbog odsustva nepotrebnih transformacija proslijeđenih parametara).
2. Ugrađene VB funkcije implementiraju samo poseban slučaj odgovarajuće API funkcije. Ovo je prilično uobičajena opcija. Na primjer, API CreateDirectory je moćniji od ugrađenog VB MkDir operatora.
3. Ogroman broj API funkcija uopšte nema analoga u trenutnoj verziji VB jezika. Na primjer, ne možete izbrisati direktorij pomoću VB-a - morate koristiti funkciju DeleteDirectory da biste to učinili.

Također treba naglasiti da se neke API funkcije (njihov udio u Win API-ju je vrlo mali) ne mogu pozvati iz VB programa zbog brojnih jezičnih ograničenja, na primjer, zbog nedostatka mogućnosti rada sa memorijskim adresama. Ali u nekim slučajevima, netrivijalne tehnike programiranja mogu pomoći (posebno u slučaju istih adresa).

Autorovo lično gledište je da umjesto proširenja sa verzije na verziju ugrađenih VB funkcija, treba dati dobar opis najčešćih API funkcija. U isto vrijeme, želio bih savjetovati programere da ne čekaju novu verziju alata s naprednim funkcijama, već da pobliže prouče postojeći Win API - vjerovatno je da su mogućnosti koje su vam potrebne mogle biti implementirane već u VB 1.0 verzija izdanja iz 1991. godine.

Kako naučiti Win API

Ovo nije tako lako pitanje, s obzirom na to da se broj Win32 API funkcija procjenjuje na oko 10 hiljada (niko ne zna tačan broj, čak ni Microsoft).

VB (verzije 4-6) uključuje datoteku sa opisom Win API deklaracija - WIN32API.TXT (više ćemo vam reći o njenoj upotrebi kasnije). Ali, prvo, može se koristiti za dobivanje informacija o svrsi određene funkcije i njenim parametrima samo pomoću korištenih mnemoničkih imena, a drugo, popis funkcija u ovoj datoteci je daleko od potpune. Jedno vrijeme (prije sedam godina) u VB 3.0 postojali su posebni fajlovi pomoći koji su opisivali Win16 API funkcije. Međutim, već u v.4.0 ove korisne informacije sa korisničkim sučeljem su nestale.

Sveobuhvatne informacije o Win32 API-ju se mogu naći u pomoći za paket za razvoj softvera platforme, koji se posebno nalazi na CD-ovima MSDN biblioteke uključenim u VB 5.0 i 6.0 Enterprise Edition i Office 2000 Developer Edition. Međutim, tamo nije nimalo lako pronaći potrebne informacije i razumjeti ih. Da ne spominjem činjenicu da su svi opisi tamo dati u vezi sa C jezikom.

Knjige poznatog američkog stručnjaka Daniela Applemana općenito su prepoznate u svijetu kao vodič za učenje API programiranja u VB okruženju. Njegova serija Visual Basic Programer's Guide to the Windows API (za Win16, Win32, primijenjena na različite verzije VB-a) je konstantno jedan od bestselera za VB programere od 1993. godine. VB 5.0 Programerski vodič za Win32 API Dana Applemana, objavljen 1997. godine, donio je autoru iz Sjedinjenih Država prijatelj koji ga je pronašao u prvoj knjižari u malom provincijskom gradu.

Ova knjiga, preko 1500 stranica, uključuje opštu metodologiju za API programiranje u VB okruženju, kao i preko 900 funkcija. Prateći CD-ROM sadrži kompletan tekst knjige i sve primjere programa, kao i nekoliko dodatnih poglavlja koja nisu uključena u štampanu verziju. Godine 1999. Dan Appleman je objavio Win32 API Puzzle Book i Tutorial za Visual Basic programere Dana Applemana, koji uključuje informacije o još 7.600 funkcija (iako manje temeljnih).

Win API i biblioteka dinamičkih veza (DLL)

Win API set je implementiran kao dinamički DLL-ovi. Dalje, zapravo ćemo govoriti o tehnologiji korištenja DLL-ova u VB okruženju na primjeru biblioteka koje su dio Win API-ja. Međutim, postoji nekoliko važnih stvari koje treba napomenuti kada govorimo o DLL-ovima.

U ovom slučaju, pod DLL-om, mislimo na tradicionalnu verziju binarnih dinamičkih biblioteka koje pružaju direktne pozive aplikacija potrebnim procedurama - potprogramima ili funkcijama (prilično na isti način kao što se dešava kada se pozivaju procedure unutar VB projekta). Takve biblioteke se mogu kreirati pomoću različitih alata: VC ++, Delphi, Fortran, osim VB-a (da vidimo šta se pojavljuje u verziji 7.0) - ovaj drugi može samo da radi ActiveX DLL-ove, kojima se pristupa preko OLE Automation interfejsa.

Obično DLL datoteke imaju ekstenziju .DLL, ali to nije neophodno (za Win16 se često koristila ekstenzija .EXE); upravljački programi vanjskih uređaja identificirani su sa .DRV.

Kao što smo napomenuli, teško je odrediti tačan broj Windows API funkcija i datoteka koje ih sadrže, ali sve se nalaze u sistemskom direktoriju. U tom smislu, bolje je istaknuti sastav biblioteka uključenih u kernel operativnog sistema, te glavne biblioteke sa ključnim dodatnim funkcijama.

Sada nekoliko savjeta.

Savjet 1. Provjerite je li vaš DL oglas ispravno formatiran L-procedure

Stvarni poziv DLL-procedurama u programu izgleda potpuno isto kao i "uobičajenim" Visual Basic procedurama, na primjer:

Pozovi DllName ([lista argumenata])

Međutim, da biste koristili eksterne DLL funkcije (uključujući Win API), one moraju biti deklarirane u programu pomoću naredbe Declare, koja izgleda ovako:

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

Deklarirajte funkciju FunctionName _ Lib “LibraryName” _ [([ArgumentList])]

Ovdje su u uglastim zagradama dati neobavezni elementi operatora, izrazi varijabli su u kurzivu, a ostale riječi su ključne riječi. Sistem pomoći pruža prilično dobar opis sintakse operatora, tako da ćemo za sada napomenuti samo nekoliko tačaka.

Deklaracije eksternih funkcija treba da budu smeštene u odeljku Opšte deklaracije modula. Ako ga stavite u modul obrasca, tada morate navesti ključnu riječ Private (ova deklaracija će biti dostupna samo unutar ovog modula) - ovo je ograničenje za sve procedure modula obrasca.

Win32 API set je implementiran samo kao funkcije (u Win16 API-ju je bilo mnogo sub-ova). Većina njih su funkcije tipa Long, koje najčešće vraćaju kod za završetak operacije.

Izjava Declare pojavila se u MS Basic-u još u vreme DOS-a, a takođe je korišćena za deklarisanje internih procedura projekta. U Visual Basicu, ovo nije potrebno jer je deklaracija internih procedura automatski njihov opis pod ili funkcija. U odnosu na Basic/DOS, u novom opisu je obavezno navesti naziv datoteke biblioteke u kojoj se nalazi tražena procedura. Wip API biblioteke nalaze se u Windows sistemskom direktoriju, tako da je dovoljno samo ime datoteke. Ako se pozivate na DLL koji se nalazi na proizvoljnoj lokaciji, morate zapisati punu putanju do ove datoteke.

Opis naredbe Declare obično zauzima puno prostora i ne stane u jedan red u prozoru koda. Stoga preporučujemo da se pridržavate neke specifične sheme prelamanja linija kada pišete aplikacije, na primjer:

Deklarirajte funkciju GetTempPath _ Lib “kernel32” Alias ​​“GetTempPathA” _ (ByVal nBufferLength As Long, _ ByVal lpBuffer kao String) Dokle god

U ovom slučaju, svi glavni elementi opisa su razmaknuti u različitim redovima i stoga su laki za čitanje.

Savjet 2. Budite posebno oprezni kada radite sa DLL funkcijama

Upotreba Win API-ja i raznih DLL funkcija značajno proširuje funkcionalnost VB-a i često poboljšava performanse programa. Međutim, kazna za ovo je rizik smanjenja pouzdanosti aplikacije, posebno tokom otklanjanja grešaka.

Jedna od najvažnijih prednosti VB okruženja je pouzdanost procesa razvoja programa: radeći pod kontrolom interpretatora, programski kod teoretski ne može poremetiti rad Windowsa i samog VB-a. Programer možda neće biti previše pažljiv u pogledu ispravnosti prosljeđivanja parametara pozvanim funkcijama - takve greške će sam interpretator lako otkriti, bilo tokom prevođenja koda, bilo tokom njegovog izvršavanja. U najneugodnijem slučaju, način obrade će jednostavno biti prekinut, uz naznaku gdje i zašto je došlo do greške.

Korišćenje Windows API-ja ili drugih DLL-ova direktno uklanja ovu kontrolu nad prenosom podataka i izvršavanjem koda izvan VB okruženja. Stoga, greška u pozivu eksternim funkcijama može dovesti do neoperabilnosti i VB-a i operativnog sistema. Ovo je posebno istinito u fazi razvoja programa, kada je prisustvo grešaka sasvim prirodno. Dakle, koristeći šire mogućnosti funkcija osnovnog sloja sistema, programer preuzima odgovornost za njihovu ispravnu upotrebu.

Problem se pogoršava činjenicom da različiti programski jezici koriste različite načine za prosljeđivanje parametara između procedura. (Tačnije, različiti načini prijenosa se koriste po defaultu, jer mnogi jezici mogu podržavati više metoda.) Win API-ji su implementirani u C / C ++ i koriste konvencije o prenošenju parametara tog sistema, koje se razlikuju od uobičajenih za VB.

S tim u vezi, treba napomenuti da je pojava analoga API funkcija ugrađenih u VB opravdana upravo prilagođavanjem potonjeg VB sintaksi i implementacijom odgovarajućeg mehanizma kontrole razmjene podataka. Imajte na umu da je u fazi eksperimentalnog otklanjanja grešaka u aplikaciji, prilikom kreiranja izvršnog modula, bolje koristiti opciju kompilacije P-koda umjesto Native Code (mašinskog koda). U prvom slučaju, program će raditi pod kontrolom interpretatora - sporije od mašinskog koda, ali pouzdanije sa stanovišta mogućeg pogrešnog uticaja na operativni sistem i pružanje pogodnijeg načina za identifikaciju mogućih grešaka.

Savjet 3: Deset najboljih praksi Dana Applemana za robusno API programiranje u VB-u

Korišćenje API funkcije zahteva pažljivije programiranje korišćenjem nekih ne baš poznatih metoda pozivanja procedura (u poređenju sa VB). Dalje ćemo se stalno baviti ovim pitanjima. A sada predstavljamo sažetak savjeta o ovoj temi koje je formulirao Dan Appleman (njihova prva verzija pojavila se još 1993. godine) s nekim našim dodacima i komentarima.

1. Zapamtite ByVal. Najčešća greška pri pristupu funkcijama API-ja i DLL-a je pogrešna upotreba ključne riječi ByVal: ili je zaborave staviti, ili je, obrnuto, stave kada nije potrebna.

Ovi primjeri pokazuju učinak ByVal operatora na prenošenje parametara

Vrsta parametra	Sa ByVal-om	Bez ByVala
Integer	Gura 16-bitni cijeli broj u stog	Gurnuo na stog 32-bitnu adresu 16-bitnog cijelog broja
Dugo	32-bitni cijeli broj se gura u stog	Gurnuo na stog 32-bitnu adresu 32-bitnog cijelog broja
String	String se konvertuje u format koji se koristi u C (podaci i završni nul bajt). 32-bitna adresa novog reda se gura u stog	Deskriptor VB linije se gura na stek. (Takve deskriptore nikada ne koristi sam Windows API, i prepoznaju se samo u DLL-ovima implementiranim posebno za VB.)

Ovdje treba podsjetiti da se parametri prosljeđuju u bilo kojem programskom sistemu, uključujući VB, na dva glavna načina: referencom (ByRef) ili vrijednosti (ByVal). U prvom slučaju se prosleđuje adresa varijable (ova opcija se podrazumevano koristi u VB), u drugom - njena vrednost. Osnovna razlika je u tome što se pomoću reference promijenjena vrijednost proslijeđenog parametra vraća pozivnom programu.

Da biste to shvatili, pokrenite eksperiment koristeći sljedeće programe:

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

Pokretanjem ovog primjera, dobićete poruku sa vrijednošću varijable jednakom 3. Činjenica je da se u ovom slučaju adresa varijable v, fizički kreirane u pozivnom programu, prosljeđuje MyProc potprogramu. Sada promijenite opis procedure u

Sub MyProc (ByVal v As Integer)

Kao rezultat toga, prilikom izvršavanja testa, dobićete v = 2, jer se samo originalna vrijednost varijable prosljeđuje proceduri - rezultat operacija izvršenih s njom se ne vraća pozivnom programu. Način prijenosa po vrijednosti također se može promijeniti korištenjem Call operatera na sljedeći način:

Sub MyProc (v As Integer) ... Pozovi MyProc ((v)) '(v) - zagrade označavaju prijenos po vrijednosti _ modu.

Međutim, kada se pozivamo na interne VB procedure, ključna riječ ByVal nije dozvoljena u naredbi Call – umjesto toga se koriste zagrade. Za ovo postoji objašnjenje.

U klasičnom slučaju (C, Fortran, Pascal), razlika između ByRef i ByVal zavisi od toga šta je tačno gurnuto u stog za razmenu podataka - adresa varijable ili njena vrednost. U Basic-u se istorijski koristi ByVal verzija softverske emulacije - adresa je uvijek na steku, ali samo kada se proslijeđuje vrijednošću, za to se kreira privremena varijabla. Za razlikovanje ove dvije opcije (Classic i Basic), koriste se različiti načini opisivanja ByVal moda. Imajte na umu da emulacija ByVal režima u VB obezbeđuje veću pouzdanost programa: zbunjujući formu poziva, programer samo rizikuje da će se ispravljena vrednost varijable (ili neće) vratiti u program koji poziva. U "klasičnoj" verziji, takva zabuna može dovesti do fatalne greške tokom izvršavanja procedure (na primjer, kada se umjesto memorijske adrese koristi vrijednost varijable jednaka, recimo, nuli).

DLL funkcije se implementiraju prema "klasičnim" principima i stoga zahtijevaju obavezan opis načina na koji se podaci razmjenjuju sa svakim od argumenata. U tu svrhu služe deklaracije funkcije kroz opis Declare (tačnije, lista prosleđenih argumenata). Najčešće se prosljeđivanje parametara u Windows API ili DLL funkciju vrši pomoću ključne riječi ByVal. Štaviše, može se specificirati i u izjavi Declare i direktno prilikom pozivanja funkcije.

Posljedice pogrešnog prenošenja parametara je lako predvidjeti. Ako primite očigledno nevažeću adresu, od vas će biti zatražena poruka GPF (General Protection Fault). Ako funkcija primi vrijednost koja odgovara valjanoj adresi, tada će API funkcija ući u tuđe područje (na primjer, jezgro Windowsa) sa svim katastrofalnim posljedicama koje slijede.

2. Provjerite tip proslijeđenih parametara. Ispravan broj i vrsta proslijeđenih parametara jednako su važni. Argumenti deklarirani u Declare moraju odgovarati očekivanim parametrima u API funkciji. Najčešća greška u prenošenju parametara povezana je s razlikom između NULL i nizova nulte dužine - zapamtite da to nije ista stvar.

3. Provjerite vrstu povrata.

VB je prilično tolerantan na nepodudarnosti tipova u povratnim vrijednostima funkcije, budući da se numeričke vrijednosti obično vraćaju preko registara, a ne preko steka. Sljedeća pravila će vam pomoći da odredite ispravnu vrijednost koju vraća API funkcija:

• DLL funkcija koja ne vraća vrijednost (analogno void u 'C') mora biti deklarirana kao VB Sub.
• API funkcija koja vraća cjelobrojnu vrijednost (Integer ili Long) može se definirati kao pod ili kao funkcija koja vraća vrijednost odgovarajućeg tipa.
• nijedna od API funkcija ne vraća brojeve s pomičnim zarezom, ali neki DLL-ovi mogu vratiti ovaj tip podataka.

4. Koristite konstrukciju "Kao bilo koji" sa velikom pažnjom. Mnoge Windows API funkcije imaju mogućnost da prihvate parametre različitih tipova i koriste konstrukciju As Any (tip se tumači ovisno o vrijednosti drugih proslijeđenih parametara).

Dobro rješenje u ovom slučaju bi bilo korištenje višestrukih alijasa funkcija, kreiranje dvije ili više deklaracija za istu funkciju, pri čemu bi svaki od opisa specificirao parametre određenog tipa.

5. Ne zaboravite inicijalizirati stringove. Postoje mnoge funkcije u Win API-ju koje vraćaju informacije učitavanjem podataka u string bafere proslijeđene kao parametar. Čini se da u vašem programu radite sve kako treba: ne zaboravite na ByVal, ispravno proslijedite parametre funkciji. Ali Windows ne može provjeriti koliko je velika memorija dodijeljena nizu. Veličina linije mora biti dovoljno velika da primi sve podatke koji se u nju mogu smjestiti. Odgovornost je VB programera da rezerviše bafer ispravne veličine.

Treba napomenuti da se u 32-bitnom Windowsu, kada se koriste stringovi, konverzija se izvodi iz Unicode-a (dvobajtno kodiranje) u ANSI (jednobajtno) i obrnuto, uzimajući u obzir nacionalne postavke sistema. Stoga je ponekad zgodnije koristiti nizove bajtova umjesto string varijabli za rezervisanje bafera. (Više o ovome u nastavku.)

Najčešće, Win API funkcije vam omogućavaju da sami definirate maksimalnu veličinu bloka. Konkretno, ponekad morate pozvati drugu API funkciju za ovo, koja će "upitati" veličinu bloka. Na primjer, GetWindowTextLength vam omogućava da odredite veličinu reda koji je potreban za smještaj naslova prozora, koji se preuzima pomoću funkcije GetWindowText. U ovom slučaju, Windows se brine da ne odete u inostranstvo.

6. Obavezno koristite opciju Explicit.

7. Pažljivo provjerite vrijednosti parametara i povratne vrijednosti. VB ima dobre mogućnosti provjere tipova. To znači da kada pokušate da prosledite nevažeći parametar VB funkciji, najgora stvar koja se može desiti je da dobijete grešku od VB. Ali ovaj mehanizam, nažalost, ne radi kada se pristupa funkcijama Windows API-ja.

Windows 9x je poboljšao validaciju parametara za većinu API funkcija. Stoga prisustvo greške u podacima obično ne uzrokuje fatalnu grešku, ali nije tako lako utvrditi što je uzrokovalo.

Ovdje možete savjetovati korištenje nekoliko načina za otklanjanje grešaka ove vrste:

• koristite način za otklanjanje grešaka u jednom koraku ili naredbu Debug.Print za provjeru svakog sumnjivog API poziva. Provjerite rezultate ovih poziva kako biste bili sigurni da je sve unutar normalnih granica i da je funkcija ispravno završena;
• koristite Windows program za otklanjanje grešaka kao što je CodeView i Windows program za otklanjanje grešaka (dostupan u Windows SDK). Ovi alati mogu otkriti greške u parametrima i barem odrediti koja API funkcija uzrokuje grešku;
• koristite dodatne alate treće strane da provjerite tipove parametara i valjanost njihovih vrijednosti. Takvi alati ne samo da mogu pronaći greške u parametrima, već čak i ukazati na red VB koda gdje se greška dogodila.

Osim toga, imperativ je provjeriti rezultat API funkcije.

8. Zapamtite da cijeli brojevi u VB-u i Windows-u nisu ista stvar. Prije svega, treba imati na umu da izraz "Integer" u VB označava 16-bitni broj, u Win dokumentaciji 32 - 32-bitni. Drugo, cijeli brojevi (Integer i Long) u VB su potpisane vrijednosti (odnosno, jedna znamenka se koristi kao znak, ostatak kao mantisa broja), u Windowsu se koriste samo nenegativni brojevi. Ovu okolnost morate imati na umu kada formirate proslijeđeni parametar pomoću aritmetičkih operacija (na primjer, izračunavanje adrese dodavanjem neke baze i pomaka). Standardne VB aritmetičke funkcije nisu prikladne za ovo. Kako biti u ovom slučaju, razgovaraćemo odvojeno.

9. Obratite posebnu pažnju na nazive funkcija. Za razliku od Win16, imena svih Win32 API funkcija su osjetljiva na tačnu upotrebu velikih i malih slova (što nije bio slučaj u Win16). Ako negdje koristite malo slovo umjesto velikog ili obrnuto, tražena funkcija neće biti pronađena. Također se pobrinite da pravilno koristite sufiks A ili W u funkcijama koje koriste parametre niza. (Pogledajte u nastavku za više o tome.)

10. Češće čuvajte svoj rad. Greške vezane za nepravilnu upotrebu DLL-a i Win API-ja mogu dovesti do abnormalnog gašenja VB okruženja, a moguće i cijelog operativnog sistema. Morate osigurati da je kod koji napišete sačuvan prije probnog pokretanja. Najjednostavnije je podesiti način automatskog snimanja projektnih modula prije pokretanja projekta u VB okruženju.

Nakon što ste pročitali prethodni savjet, mogli biste pomisliti da je korištenje Win API funkcija rizičan posao. Donekle, to je tačno, ali samo u poređenju sa sigurnim programiranjem koje obezbeđuje sam VB. Ali uz njihovu vještu primjenu i poznavanje mogućih zamki, ovaj rizik je minimalan. Osim toga, često je jednostavno nemoguće potpuno napustiti korištenje Win API-ja - oni će i dalje biti potrebni za bilo kakav ozbiljan razvoj.

Osim toga, ranije smo spomenuli zamke za široku klasu DLL-ova. U slučaju Win API-ja, sve je mnogo jednostavnije, jer je oblik pozivanja ovih funkcija ovdje jasno objedinjen. U ovom slučaju treba imati na umu sljedeće glavne tačke:

1. Win32 API funkcije su samo funkcije, odnosno procedure tipa Function (u Win16 API-ju je bilo mnogo Subs-ova). Sve su to funkcije tipa Long, tako da su njihovi opisi napisani u sljedećem obliku: Declare Function name... As Long 'tip funkcije _ je eksplicitno definiran

   Deklarirajte naziv funkcije & 'tip funkcije _ definiran je sufiksom

   Poziv API funkcije izgleda ovako:

Rezultat & = ApiName & ([ Lista argumenata]

1. Najčešće, povratna vrijednost funkcije je kod za izlaz iz operacije. Štaviše, vrijednost koja nije nula znači u ovom slučaju normalan završetak, nulta vrijednost znači grešku. Obično (ali ne uvijek) možete razjasniti prirodu greške pozivanjem funkcije GetLastError. Opis ove funkcije izgleda ovako: Objavite funkciju GetLastError & Lib “kernel32” ()

   PAŽNJA! Kada radite u VB-u, bolje je koristiti LastDLLERror svojstvo Err objekta da dobijete vrijednost kvalificiranog koda greške, jer će ponekad VB resetirati funkciju GetLastError između API poziva i nastavka izvršavanja programa.

   Možete protumačiti kod koji je vratio GelLastError koristeći konstante zapisane u datoteci API32.TXT, s imenima koja počinju sufiksom ERROR_.

   Najčešće greške imaju sljedeće kodove:

   • ERROR_INVALID_HANDLE = 6 & - nevažeća ručka
   • ERROR_CALL_NOT_IMPLEMENTED = 120 & - pozovite u Windows 9x funkciju koja je dostupna samo za Windows NT
   • ERROR_INVALID_PARAMETER = 87 & - nevažeća vrijednost parametra

   Međutim, mnoge funkcije vraćaju vrijednost nekog traženog parametra (na primjer, OpenFile vraća vrijednost deskriptora datoteke). U takvim slučajevima greška se identifikuje pomoću nekog drugog posebnog povrata i vrijednosti, najčešće 0 ili –1.

2. Win32 API-ji koriste strogo fiksirane načine prosljeđivanja najjednostavnijih tipova podataka. a) ByVal ... As Long

   Duge varijable obavljaju najmanje 80% prosljeđivanja argumenata. Imajte na umu da argument uvijek iza koje slijedi ključna riječ ByVal, što između ostalog znači da se vrši jednosmjerni prijenos podataka - od VB programa do API funkcije.

   B) ByVal ... Kao String

   Ova vrsta prenosa podataka se takođe dešava prilično često, i to uz argument uvijek ByVal je primijenjen. Kada se pozove API funkcija, adresa stringa se upisuje u stog, tako da je u ovom slučaju moguća dvosmjerna razmjena podataka. Postoji nekoliko zamki koje treba uzeti u obzir pri radu sa žicama.

   Prvo, memorija za string je rezervisana u programu koji poziva, tako da ako API funkcija ispunjava nizove, onda morate da kreirate niz potrebne veličine pre nego što ga pozovete. Na primjer, funkcija GetWindowsDirectory vraća putanju do Windows direktorija, koji po definiciji ne bi trebao biti duži od 144 znaka. U skladu s tim, poziv ove funkcije trebao bi izgledati otprilike ovako:

   WinPath $ = Space $ (144) 'rezervirajte niz od _ 144 karaktera Rezultat & = GetWindowsDirectory & (WinTath $, 144) _' popunite bafer 'Rezultat & - stvarni broj znakova u nazivu direktorija _ WinPath $ = lijevo $ (WinPath, rezultat &)

   Drugi problem je što kada se pozove API funkcija, originalni string se konvertuje u neki interni prikaz, a kada se funkcija izađe, obrnuto. Ako se u danima Win16 ova operacija sastojala samo od dodavanja nula bajta na kraju niza, onda je s pojavom Win32 to dopunjeno transformacijom dvobajtnog Unicode kodiranja u ANSI i obrnuto. (O tome je detaljno razmotreno u članku "Osobine rada sa string varijablama u VB", ComputerPress 10'99 i 01'2000). Za sada, napominjemo da koristeći ByVal ... Kao String konstrukciju, možete razmjenjivati ​​nizove samo sa znakovnim podacima.

   B) ... Kao bilo koji

   To znači da će neka adresa memorijskog bafera biti gurnuta u stog, čiji će sadržaj biti interpretiran od strane API funkcije, na primjer, ovisno o vrijednosti drugih argumenata. Međutim, As Any se može koristiti samo u izjavi Declare - za određeni poziv funkciji, određena varijabla mora biti definirana kao argument.

   D) ... Kao UserDefinedType

   Ovaj dizajn se također često koristi kada je potrebno razmjenjivati ​​podatke (uglavnom u oba smjera) koristeći neku strukturu. U stvari, ova konstrukcija je svojevrsna konkretna implementacija oblika prijenosa As Any, ali u ovom slučaju, funkcija je konfigurirana za fiksnu strukturu.

   Oblik strukture podataka određen je specifičnom API funkcijom, a odgovornost je programera da je ispravno opiše i rezerviše u programu koji poziva. Ovaj dizajn uvijek koristi bez riječi ByVal, odnosno u ovom slučaju se vrši prijenos po referenci - adresa varijable se upisuje u stek.

Primjer pozivanja API funkcije

Ilustrirajmo gore navedeno primjerom korištenja dvije korisne funkcije za rad s datotekama - lopen i lread, koje su opisane na sljedeći način:

Deklarirajte funkciju lopen Lib “kernel32” _ Alias ​​“_lopen” (_ ByVal lpFileName kao string, _ ByVal wReadWrite As Long) As Long Deklarirajte funkciju lread Lib “kernel32” _ Alias ​​“_lread” (_ ByVal hFile As Long, lpBuffer As Any, _ ByVal wBytes As Long) Dokle god

U VB-u, njihove kolege — u ovom slučaju, tačne — su izjave Open i Get (za binarni način). Odmah obratimo pažnju na upotrebu ključne riječi Alias ​​u deklaraciji funkcije - to je upravo slučaj kada ne možete bez nje. Prava imena funkcija u biblioteci počinju donjom crtom (tipičan C stil), što nije dozvoljeno u VB-u.

Operacija otvaranja datoteke može izgledati ovako:

Const INVALID_HANDLE_VALUE = -1 'nevažeća _ vrijednost deskriptora lpFileName $ = “D: \ calc.bas”' naziv datoteke wReadWrite & = 2 'read-write mode hFile & = lopen (lpFileName $, wReadWrite &) _' definirajte opis datoteke ili hFile & = INVALID_HANDLE_VALUE Onda _ 'greška pri otvaranju datoteke' pojašnjava kod greške CodeError & = Err.LastDllError 'CodeError & = GetLastError _' ova konstrukcija ne radi. Kraj ako

Ovdje treba napomenuti dvije stvari:

• kao vrijednost funkcije dobijamo vrijednost deskriptora datoteke. Greška odgovara vrijednosti –1;
• samo u ovom slučaju, poziv funkcije GetLastError ne radi - da bismo dobili navedenu vrijednost greške, okrenuli smo se objektu Err (o mogućnosti takve situacije smo govorili gore).

Zatim možete pročitati sadržaj datoteke, ali to pretpostavlja da programer mora imati neko razumijevanje njene strukture (baš kao što to čini kada se radi sa proizvoljnim binarnim datotekama). U ovom slučaju, poziv funkcije lread može izgledati ovako:

Dim MyVar As Single wBytes = lread (hFile &, MyVar, Len (MyVar) 'pročitani pravi broj, 4 bajta' wBytes - broj stvarno pročitanih podataka,' -1 - greška ... Upišite MyStruct x As Single i As Integer End Upišite Dim MyVar As MyStruct wBytes = lread (hFile &, MyVar, Len (MyVar)) 'čitana struktura podataka, 6 bajtova

Napomena: drugi argument funkcije se prosljeđuje referencom, ostali se prosljeđuju po vrijednosti.

Dim MyVar As String MyVar = Space $ (10) 'rezerviraj varijablu za 10 znakova wBytes = lread (hFile &, ByVal MyVar, Len (MyVar))' čita niz znakova, 10 znakova

Ovdje možete vidjeti važnu razliku u odnosu na prethodni primjer - varijablu stringa obavezno prati ključna riječ ByVal.

Čitanje sadržaja datoteke u nizu (radi jednostavnosti koristićemo jednodimenzionalni niz bajtova) se radi na sljedeći način:

Dim MyArray (1 do 10) Kao bajt wBytes = lread (hFile &, MyArray (1), _ Len (MyArray (1)) * 10) 'čitaj 10 elemenata niza

Navođenjem prvog elementa niza kao argumenta, prosljeđujemo adresu početka memorijskog područja rezerviranog za niz. Očigledno, svaki fragment niza može se popuniti na ovaj način:

WBytes = lread (hFile &, MyArray (4), _ Len (MyArray (1)) * 5) 'čitaj elemente niza 4 do 8

Savjet 5. Koristite Alias ​​za Gears i parametri As Any

Ovdje ćemo, na osnovu prethodnog primjera, otkriti suštinu četvrtog savjeta Dana Applemana.

Kada radite sa funkcijom lread, zapamtite da kada joj pristupate pomoću varijable stringa, morate koristiti ključnu riječ ByVal (u suprotnom se ne može izbjeći poruka o nedozvoljenoj operaciji). Da biste bili sigurni, možete napraviti dodatni poseban opis iste funkcije da radi samo sa string varijablama:

Deklarirajte funkciju lreadString Lib “kernel32” _ Alias ​​“_lread” (_ ByVal hFile As Long, ByVal lpBuffer kao String, _ ByVal wBytes As Long) Dokle god

Kada radite s ovim opisom, više ne morate specificirati ByVal kada pristupate:

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

Čini se da vam sintaksa izjave Declare omogućava da napravite sličan poseban opis za niz:

Deklarirajte funkciju lreadString Lib “kernel32” Alias ​​“_lread” (_ ByVal hFile As Long, lpBuffer () kao bajt, _ ByVal wBytes koliko dugo)

Međutim, žalba

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

neizbježno dovodi do fatalne programske greške.

Ovo je nastavak razgovora o posebnostima obrade string varijabli u Visual Basicu: VB koristi dvobajtno Unicode kodiranje, Win API - jednobajtni ANSI (i sa formatom prihvaćenim u C - sa nultim bajtom na kraj). Shodno tome, kada se koriste varijable niza kao argument, konverzija iz Unicodea u ANSI se uvijek automatski izvodi kada se pozove API funkcija (tačnije, DLL funkcija), a obrnuta konverzija se izvodi na povratku.

Izvod iz ovoga je jednostavan: koristeći String varijable možete razmjenjivati ​​znakovne podatke, ali ih ne možete koristiti za razmjenu proizvoljnih binarnih informacija (kao što je bio slučaj sa 16-bitnim verzijama VB-a). U potonjem slučaju, bolje je koristiti jednodimenzionalni niz bajtova.

Kao što znate, tip String se može koristiti za opisivanje prilagođene strukture. S tim u vezi, treba imati na umu sljedeće:

• Kategorički je nemoguće koristiti sljedeću konstrukciju za upućivanje na Win API: Tip MyStruct x As Single s As String 'string promjenjive dužine End Type

  U slučaju niza promjenljive dužine, deskriptor stringa se prosljeđuje kao dio strukture sa svim posljedicama koje proizilaze u obliku greške u izvršavanju programa.

• Možete koristiti niz fiksne dužine kao element strukture: upišite MyStruct x As Single s Kao string * 8 'string fiksne dužine End Type

U ovom slučaju se vrši odgovarajuća konverzija kodiranja.

I posljednja napomena: ni u kom slučaju ne možete koristiti niz varijabli niza (i fiksne i promjenjive dužine) kada pozivate API funkciju. U suprotnom, izgled "ilegalne operacije" će biti zagarantovan.

Vrlo je vjerovatno da ćete naići na situaciju u kojoj morate napisati vlastite DLL funkcije. Potreba za tim će se neizbježno pojaviti ako koristite tehnologiju miješanog programiranja - korištenje dva ili više programskih jezika za implementaciju jedne aplikacije.

Imajte na umu da je mješovito programiranje prilično uobičajeno za prilično složenu aplikaciju. Zaista, svaki jezik (tačnije, sistem programiranja zasnovan na jeziku) ima svoje prednosti i slabosti, pa je sasvim logično koristiti prednosti različitih alata za rješavanje različitih problema. Na primjer, VB - za kreiranje korisničkog interfejsa, C - za efikasan pristup sistemskim resursima, Fortran - za implementaciju numeričkih algoritama.

Autorovo mišljenje je da svako ozbiljno programiranje zahtijeva od programera posjedovanje najmanje dva alata. Naravno, u savremenim uslovima jasne podele rada, veoma je teško biti odličan stručnjak čak i u dva sistema, pa je shema „glavni i pomoćni jezici“ logičnija. Ideja je da čak i površno poznavanje "pomoćnog" jezika (pisanje prilično jednostavnih procedura) može uvelike povećati efikasnost "glavnog" jezika. Imajte na umu da je poznavanje VB-a, barem kao pomoćnog, danas gotovo obavezan uslov za profesionalnog programera. Inače, u danima DOS-a za svakog programera, uključujući i Basic, bilo je vrlo poželjno poznavati osnove Assemblera.

Na ovaj ili onaj način, ali čak iu uvjetima grupnog rada, kada se svaki programer bavi svojim specifičnim poslom, svi učesnici projekta trebali bi imati predstavu o karakteristikama proceduralnog sučelja na različitim jezicima. I da znate da mnogi sistemi programiranja (uključujući VB), pored podrazumevanog interfejsa, omogućavaju korišćenje drugih, proširenih metoda upućivanja na procedure, koje omogućavaju prilagođavanje interfejsa drugom jeziku.

Kada proučavate međuproceduralno sučelje, obratite pažnju na sljedeće moguće zamke:

• Različiti jezici mogu koristiti različite konvencije za pisanje identifikatora. Na primjer, donja crta se često koristi na početku naziva procedure, što je zabranjeno u VB. Ovaj problem se lako rješava korištenjem ključne riječi Alias ​​u izjavi Declare (pogledajte primjer savjeta 2.3).
• Može se koristiti drugačiji redoslijed pisanja proslijeđenih argumenata u stog. Na primjer, u danima DOS-a (iskreno ne znam kako to sada izgleda u Windows-u), C je pisao argumente s kraja liste, ostali jezici (Fortran, Pascal, Basic) - od početka.
• Standardno se koriste različiti principi prosljeđivanja parametara - po referenci ili po vrijednosti.
• Različiti principi pohranjivanja string varijabli. Na primjer, u C (kao i u Fortranu i Pascalu) dužina stringa je definirana nultim bajtom na njegovom kraju, dok je u Basic-u dužina eksplicitno zapisana u deskriptoru stringa. Naravno, morate imati na umu mogućnost korištenja različitih kodiranja znakova.
• Kada prenosite višedimenzionalne nizove, zapamtite da postoje različite opcije za pretvaranje višedimenzionalnih struktura u jednodimenzionalne (počevši od prvog indeksa ili od posljednjeg, u odnosu na dvodimenzionalne nizove - "po redovima" ili "po kolonama").

Uzimajući sve ovo u obzir, mogu se formulirati sljedeće preporuke:

• Koristite najjednostavnije, provjerene načine za prosljeđivanje argumenata DLL funkcijama. Standardi usvojeni za Win API su dobri primjeri.
• Ni pod kojim okolnostima nemojte prosljeđivati ​​nizove varijabli niza.
• Koristite vrlo pažljivo prosljeđivanje jednostavnih string varijabli i višedimenzionalnih nizova.
• Obavezno posebno provjerite funkcionalnost mehanizma za prosljeđivanje argumenata u i iz pozvane procedure. Napišite prilagođeni test za testiranje prijenosa podataka. Zasebno provjerite da li je svaki argument ispravno proslijeđen. Na primjer, ako imate proceduru s nekoliko argumenata, prvo provjerite da li je svaki parametar ispravno proslijeđen za varijantu s jednim argumentom, a tek onda za cijelu listu.

Ali šta ako je DLL funkcija već napisana, na primjer, u Fortranu, ali njen ulazni interfejs se ne uklapa dobro sa gornjim VB standardima? Ovdje možete dati dva savjeta. Prvo, napišite probnu DLL funkciju i upotrijebite je da pokušate pronaći pravi poziv iz VB-programa pokušajem i greškom. Drugo: napišite adaptornu proceduru u istom Fortranu, koja bi pružila jednostavan interfejs između VB-a i DLL funkcije sa pretvaranjem jednostavnih struktura podataka u složene (na primjer, pretvaranje višedimenzionalnog niza bajtova u niz nizova).

Dakle: koristite DLL funkcije. Ali budite na oprezu...

ComputerPres 9 "2000

API definira funkcionalnost koju program (modul, biblioteka) pruža, dok API vam omogućava da apstrahujete od toga kako je ta funkcionalnost implementirana.

Ako se program (modul, biblioteka) smatra crnom kutijom, tada je API skup "dugmića" koji su dostupni korisniku ove kutije, a koje on može vrtjeti i povlačiti.

Softverske komponente komuniciraju jedna s drugom preko API-ja. U ovom slučaju, komponente obično formiraju hijerarhiju - komponente visokog nivoa koriste API komponenti nižeg nivoa, a one zauzvrat koriste API komponenti još nižeg nivoa.

Prema ovom principu, nadograđuju se protokoli za prijenos podataka. Standardni Internet protokol (OSI mrežni model) sadrži 7 slojeva (od fizičkog sloja prijenosa bitnih paketa do sloja aplikacijskih protokola kao što su HTTP i IMAP). Svaki sloj koristi prednosti funkcionalnosti prethodnog sloja prijenosa podataka i, zauzvrat, pruža željenu funkcionalnost sljedećem sloju.

Važno je napomenuti da je koncept protokola po značenju blizak konceptu API-ja. I jedno i drugo su apstrakcije funkcionalnosti, samo što je u prvom slučaju riječ o prijenosu podataka, a u drugom - o izgradnji računalnih aplikacija.

API biblioteke funkcija i klasa uključuje opis potpisi i semantika funkcije.

Application Programming Interface (API) je programski interfejs za interakciju između sistema koji omogućava:

• Pristupite poslovnim uslugama preduzeća
• Razmjena informacija između sistema i aplikacija
• Pojednostavite interakcije između kompanija, partnera, programera i kupaca

Otvorena API strategija

API strategija uključuje:

• Razvoj poslovnih proizvoda baziranih na postojećim API-jima
• Pružanje internih usluga programerima
• API modeli monetizacije za izgradnju višekanalnih interakcija i povećanje profita

Implementacija Open API koncepta pomaže transformaciji poslovanja, ugrađivanju u fleksibilni projektni ekosistem tržišnih igrača, stvaranju uslova za stalno generisanje novih ideja i formiranje dodatne vrednosti u upravljanju korporativnim nizovima podataka.

Tržište integracijskih rješenja razvija se u kontekstu evolucije API-ja - od EDI-a i SOAP-a do Web 2.0, čime je započela era javnih API-ja. Broj takvih interfejsa u naredne 3 godine može porasti više od 50 puta i dostići 1 milion. To je zbog višekanalnosti: kanali interakcije s kupcima moraju se mijenjati s njima. Kontinuirani rast broja potrošača i obima podataka doveo je do pojave API ekonomije, koja pomaže u kreiranju inovativnih poslovnih modela za korištenje sredstava i usluga preduzeća zasnovanih na otvorenim interfejsima.

Potpis funkcije

Potpis funkcije- dio generičke deklaracije funkcije koja omogućava emiterima da identifikuju funkciju između ostalih. Različiti programski jezici imaju različite ideje o potpisu funkcije, što je također usko povezano s mogućnostima preopterećenja funkcija u ovim jezicima.

Ponekad razlikovati pozivni potpis i potpis implementacije funkcije. Potpis poziva se obično konstruiše iz sintaktičke strukture poziva funkcije, uzimajući u obzir potpis opsega date funkcije, naziv funkcije, redoslijed stvarnih tipova argumenata u pozivu i tip rezultat. Signatura implementacije obično uključuje neke elemente iz sintaktičke konstrukcije deklaracije funkcije: specifikaciju opsega funkcije, njeno ime i slijed formalnih tipova argumenata.

Na primjer, u programskom jeziku C ++, jednostavnu funkciju kompajler nedvosmisleno prepoznaje po njenom imenu i nizu tipova njegovih argumenata, što čini potpis funkcije u ovom jeziku. Ako je funkcija metoda neke klase, tada će i ime klase biti uključeno u potpis.

Također treba napomenuti da programer često ima na raspolaganju nekoliko različitih API-ja koji omogućavaju postizanje istog rezultata. Međutim, svaki API se obično implementira koristeći API softverskih komponenti nižeg nivoa apstrakcije.

Na primjer: da biste vidjeli redak "Zdravo, svijet!" sve što treba da uradite je da kreirate HTML dokument sa minimalnim naslovom i jednostavnim telom koje sadrži dati niz. Šta se dešava kada pretraživač otvori ovaj dokument? Program pretraživača će prenijeti naziv datoteke (ili već otvoren deskriptor datoteke) u biblioteku koja obrađuje HTML dokumente, koja će, zauzvrat, koristeći API operativnog sistema, pročitati ovu datoteku i razumjeti njen uređaj, pozvati operacije poput "Obriši prozor", "piši odabranim fontom Zdravo, svijet!" ovo".

Istovremeno, praktično na svakom od nivoa, zapravo postoji nekoliko mogućih alternativnih API-ja. Na primjer: mogli bismo napisati originalni dokument ne u HTML-u, već u LaTeX-u, za prikaz možemo koristiti bilo koji pretraživač. Različiti pretraživači generalno koriste različite HTML biblioteke, a osim toga, sve se može (općenito govoreći) kompajlirati koristeći različite primitivne biblioteke i na različitim operativnim sistemima.

Dakle, glavni izazovi postojećih slojevitih API sistema su:

• Složenost prenošenja programskog koda s jednog API sistema na drugi (na primjer, prilikom promjene OS-a);
• Gubitak funkcionalnosti pri prelasku sa nižeg nivoa na viši. Grubo govoreći, svaki API "sloj" kreiran je da olakša neki standardni skup operacija. Ali u isto vrijeme, stvarno postaje teško, ili postaje fundamentalno nemoguće izvesti neke druge operacije koje pruža niži API nivo.

Osnovni tipovi API-ja

Interni API

• API pristup je omogućen samo internim programerima
• Aplikacije namijenjene zaposlenima u preduzeću

Poslovni pokretači:

• Konzistentnost razvoja
• Smanjeni troškovi
• Poboljšanje efikasnosti razvoja

Partnerski API-ji

• API-ji su dostupni samo ograničenom skupu poslovnih partnera
• Aplikacije su namijenjene krajnjim potrošačima i poslovnim korisnicima

Poslovni pokretači:

• Automatizacija procesa razvoja
• Razvoj partnerstava
• Optimizacija procesa interakcije sa partnerima

Javni API-ji

Pristup je omogućen svim vanjskim programerima. Aplikacije su namijenjene krajnjim korisnicima

Poslovni pokretači:

• Razvoj novih usluga
• Razvoj ekosistema
• Višekanalna interakcija

Najpoznatiji API-ji

API operativnih sistema

GUI API

• Direct3D (dio DirectX-a)
• DirectDraw (dio DirectX-a)

Možete doživjeti i radost i frustraciju kada radite s API-jem. S jedne strane, interakcijom s drugim aplikacijama, možete uvelike povećati doseg publike i "wow" efekat vaše aplikacije. S druge strane, ovo uključuje čitanje tone dokumentacije, učenje o strategijama provjere autentičnosti i raščlanjivanje neinformativnih (ili čak nedostajućih) poruka o greškama.

Prije svega, ako još uvijek ne razumijete u potpunosti što je API (Aplikacijsko programsko sučelje), pročitajte Skillcrush objašnjenje, a zatim prvi dio ovog članka da nadoknadite korak.

"API" je neverovatno širok koncept - svaki put kada vaša aplikacija "razgovara" sa drugom aplikacijom, to se dešava preko API-ja. Komponente unutar vaše aplikacije, poput različitih dijelova Railsa, također komuniciraju jedna s drugom preko API-ja. Oni su manje-više nezavisne pod-aplikacije koje prenose podatke koji su svakoj od njih potrebni za obavljanje svojih specifičnih zadataka. U svijetu aplikacija, sve je API!

Kada kreirate aplikacije sa dinamičnijom prednjom funkcionalnošću (i jednostranične Javascript aplikacije i jednostavne aplikacije sa zasebnim AJAX pozivima), one će komunicirati sa Rails backend-om preko vašeg sopstvenog API-ja, što je zapravo samo nekoliko dodatnih linija koda. govoreći vašim kontrolerima kako da služe JSON ili XML umjesto HTML-a.

U ovom vodiču ćete naučiti kako kreirati vlastiti API. U narednim lekcijama ćemo naglasiti kako komunicirati sa API-jima iz drugih aplikacija. Lekcije bi trebale biti dobra odskočna daska za učenje ove teme, ali je malo vjerovatno da će moći u potpunosti pokriti sve slučajeve. Većina rada sa API-jima je znati kako pročitati njihovu dokumentaciju i shvatiti šta žele od vas.

Tačke za razmišljanje

Pregledajte pitanja i provjerite znate li odgovore. Ponovo se provjerite nakon dovršetka zadatka.

• Kako Rails razumije koju vrstu datoteke očekujete kao odgovor kada napravite HTTP zahtjev.
• Koja je svrha metode #respond_to?
• Kako vraćate objekt User dok specificirate atribute za koje ne želite da budu uključeni u taj objekt (to jest, ne možete samo vratiti User.first)?
• Koja su 2 koraka iza scene #to_json metode?
• Kako da kažem radnji kontrolera da prikaže samo poruku o grešci?
• Kako da kreiram sopstvenu poruku o grešci?
• Zašto ne možete koristiti metode provjere autentičnosti kontrolera zasnovane na sesiji ako želite dozvoliti programske veze sa svojim API-jem?
• Šta je servisno orijentirana arhitektura?

Osnove API-ja

Vaša Rails aplikacija je zapravo već API, iako je možda ne mislite kao API. Web pretraživač koji vaši korisnici pokreću je također program, tako da on zapravo šalje API zahtjev vašoj Rails aplikaciji kada korisnik otvori novu stranicu. Nekada smo razmišljali na taj način jer je renderiranje HTML predložaka toliko uobičajen zadatak da ovu funkcionalnost jednostavno kodiramo u naše serverske programe kao standardni tip odgovora, a sve ostalo smatramo neobičnim.

Međutim, često poželite da uputite zahtev koji ne zahteva da prođete kroz sve glavobolje korišćenja vašeg pretraživača. Možda vam nije stalo do strukture stranice (HTML), ali želite čiste podatke zauzvrat. Recimo da želite da dobijete listu svih korisnika. Možete zatražiti nešto poput http://yourapplication.com/users, što će najvjerovatnije pokrenuti akciju #index i prikazati listu svih korisnika u aplikaciji.

Ali zašto se mučiti sa svim ovim nepotrebnim informacijama kada je sve što želite je da dobijete listu korisnika? Najlakša opcija bi bila da pošaljete zahtjev na isti URL, navodeći očekivanje JSON ili XML odgovora zauzvrat. Ako pravilno postavite svoj Rails kontroler, vratit ćete jednostavan JSON objekt niza koji sadrži sve korisnike. Divno!

Isti princip se primjenjuje kada komunicirate s vanjskim API-jem. Recimo da želite da dobijete nedavne "tvitove" korisnika sa Twitter-a. Sve što treba da uradite je da kažete vašoj Rails aplikaciji kako da komunicira sa Twitter API-jem (tj. da se autentifikuje), podnese zahtev i obradi skup tvitova koji su vraćeni.

Kreiranje API-ja

Možda želite da svoju Rails aplikaciju učinite čistim API backend-om za front-end web stranice, ili jednostavno želite naučiti kako poslati JSON kada front-end to zatraži. Ovaj odjeljak neće pokriti kako kreirati kompletne RESTful API-je s funkcijom provjere autentičnosti. Ovo je jednostavan uvod u tretiranje vaše aplikacije kao API-ja.

Osnove

Ako želite da vaša Rails aplikacija vraća JSON umjesto HTML-a, trebate reći svom kontroleru da to učini. Odlična stvar je što ista radnja kontrolera može vratiti različite tipove u zavisnosti od toga da li vaš korisnik postavlja redovan zahtjev iz pretraživača ili pristupa API-ju preko komandne linije. Ovo određuje koji je tip zahtjeva napravljen na osnovu ekstenzije tražene datoteke, na primjer example.xml ili example.json.

Možete provjeriti šta Rails "misli" o tipu datoteke koji očekujete tako što ćete provjeriti zapisnik servera:

Započeo GET "/ posts / new" za 127.0.0.1 u 2013-12-02 15:21:08 -0800 Obrada od strane PostsController # novo kao HTML

Prvi red vam govori koji je URL zatražen, a drugi vam govori kamo je usmjeren i kako Rails njime rukuje. Ako koristite ekstenziju .json, to bi izgledalo ovako:

Započeo GET "/posts.json" za 127.0.0.1 u 2013-12-04 12:02:01 -0800 Obrada od strane PostsController # indeks kao JSON

Ako imate pokrenutu probnu aplikaciju, pokušajte zatražiti različite URL-ove. Ako vaš kontrolor ne zna kako da rukuje njima, onda možete dobiti grešku, ali ipak biste trebali vidjeti šta Rails razumije po vašim zahtjevima.

Rendering JSON ili XML

Kada odlučite da želite odgovoriti na zahtjeve pomoću JSON-a ili XML-a, trebate reći svom kontroleru da prikaže JSON ili XML umjesto HTML-a. Jedan od načina da to učinite je korištenje metode #respond_to:

Class 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

U ovom slučaju, #respond_to prosljeđuje objekt formata u blok, kojem možete priložiti odgovarajući poziv za renderiranje. Ako ništa ne učinite, html će se prikazati koristeći standardni Rails šablon (app / views / index.html.erb u ovom primjeru).

Funkcija #render je dovoljno pametna da shvati kako renderirati širok izbor formata. Kada mu proslijedite ključ: json, on će pozvati #to_json na vrijednosti, u ovom primjeru @users. Ovo će pretvoriti vaše Ruby objekte u JSON nizove, koji će biti proslijeđeni aplikaciji koja traži.

Na ovaj način dobijate svoj API. Naravno, kreiranje API-ja može biti malo složenije ako želite da radite neke neobične stvari, ali sve se drži osnova.

Određivanje atributa povrata

Recimo da želite da budete sigurni da ne vraćate adresu e-pošte korisnika zajedno sa objektom User. U ovom slučaju, htjet ćete promijeniti atribute koji će biti vraćeni, mijenjajući ono što #to_json metoda radi.

Ranije ste jednostavno nadjačali metodu #to_json sa svojom verzijom, ali sada vam to nije potrebno - u stvari, umjesto toga ćete nadjačati metodu #as_json. Metoda #as_json se koristi u metodi #to_json, tako da njeno modificiranje implicitno mijenja rezultat #to_json, ali na prilično specifičan način.

#to_json radi 2 stvari: pokreće #as_json i dobija hash atributa koji će biti prikazan u JSON-u. Zatim se prikazuje u JSON koristeći ActiveSupport :: json.encode. Dakle, modifikacijom #as_json, vi ste precizniji u vezi sa delom metode #to_json koji zapravo želite da promenite.

U našem slučaju, to radimo modificiranjem #as_json u našem modelu da vrati samo atribute koji su nam potrebni:

# aplikacija / modeli / korisnik.rb klasa Korisnik< ActiveRecord::Base # Вариант 1: Полное переопределение метода #as_json def as_json(options={}) { :name =>self.name) # NE Uključujte kraj polja e-pošte # Opcija 2: Koristite standardni metod #as_json def as_json (options = ()) super (samo: [: ime]) end end

Zatim, u našem kontroleru, samo trebamo prikazati JSON kao i obično (u primjeru ispod, JSON će uvijek biti vraćen, bez obzira da li je HTML zahtjev poslan ili ne):

# aplikacija / kontroleri / users_controller.rb klasa UsersController< ApplicationController def index render json: User.all end end

Imajte na umu da ne morate sami pozvati #to_json kada koristite #render - on to radi umjesto vas.

Ponekad Heroku može zahtijevati dodatne korake za ispravan prikaz vaših stranica s greškama. Pogledaj. Možda ćete prvo morati ukloniti statične stranice iz direktorija aplikacije / javnog.

Sigurnost izvana

Recimo da želite dozvoliti pristup API-ju samo ako je korisnik prijavljen. Vaša postojeća autentifikacija u kontroleru već radi svoj posao - samo provjerite da li imate ispravan set #before_action (kao before_action: require_login). Možda će vam trebati funkcionalnost kada i prijavljeni i neprijavljeni korisnici mogu vidjeti stranicu, ali svi bi trebali vidjeti različite podatke. Ne želite da neprijavljeni korisnici mogu postavljati API zahtjeve za dobivanje osjetljivih podataka. Isto tako, ne želite dopustiti neovlaštenim korisnicima da posjećuju određene HTML stranice.

Ako želite obraditi zahtjeve iz aplikacije koja nije pretraživač (kao što je komandna linija), ne možete se osloniti na kolačiće pretraživača za autentifikaciju. Zbog toga većina API-ja koristi vlastite tokene kao dio procesa provjere autentičnosti. Pričaćemo malo više o tokenima u sledećem tutorijalu.

Sljedeći koraci

Sada imate vještine da koristite svoju Rails aplikaciju za posluživanje ne samo HTML-a, već bilo kojeg drugog formata. Ako želite da idete dalje i dozvolite drugim programerima da naprave nešto koristeći vašu platformu (na primer, tako da mogu da postavljaju programske zahteve umesto da se autentifikuju kao korisnik), moraćete da učinite svoj API sistem mnogo sigurnijim. Nećemo sve ovo ovdje pokrivati, ali pogledajte sljedeće resurse:

• Članak Building Awesome Rails APIs opisuje mnoge od najboljih pristupa za prelazak sa aplikacije igračaka na industrijske API standarde.

Servisno orijentisana arhitektura

Vrijeme je da uvedemo arhitektonski pristup koji se zove Service-Oriented Architecture (SOA). Osnovna ideja je da će se vaša aplikacija sastojati od mnogo servisa kao što su sistem plaćanja, registracija korisnika, modul preporuke itd. Umjesto da sve ovo gradite unutar jedne glavne aplikacije, vi razbijate podsisteme na potpuno nezavisne dijelove koji međusobno komuniciraju koristeći interne API-je.

Ovo je dobro iz mnogo razloga. Budući da svaki dio vaše aplikacije ne brine o tome kako drugi dijelovi rade, i samo zna kako da traži podatke preko njihovog API-ja, možete napraviti značajne promjene u kodu usluge, a ostatak aplikacije će raditi kao i prije. Možete u potpunosti zamijeniti jednu uslugu drugom, i sve dok je u interakciji koristeći iste API metode, to će ići vrlo glatko. Možete koristiti eksterne API-je kao dio svoje aplikacije (kao što su sistemi plaćanja) umjesto da pišete svoje. Možete kreirati PHP aplikaciju koja je u interakciji sa Python aplikacijom koja je u interakciji sa Rails aplikacijom, i sve će raditi, jer oni međusobno komuniciraju koristeći API.

Općenito je dobra ideja pokušati učiniti svaki dio vaše aplikacije što je moguće nezavisnijim. Koncept SOA-e podstiče vas da razmišljate u smislu tačno koje metode želite da izložite drugim delovima vaše aplikacije, a takođe čini vaš kod boljim. Osim toga, uz pretpostavku da je svaka glavna komponenta vaše aplikacije nezavisna, također možete mnogo lakše izolirati probleme i rješavati greške na smisleniji način.

Korištenje uslužno orijentirane arhitekture za cijelu aplikaciju je kao razbijanje ogromne, složene Ruby skripte na odlične klase i metode, samo u većem obimu.

Jedan od najpoznatijih slučajeva prelaska na servisno orijentisanu arhitekturu je Amazon.com. Jednog dana 2002. Jeff Bezos je otvoreno izjavio da sve radne grupe treba da odu u SOA-u ili da budu otpuštene. Notorious blog post zaposlenik Google-a, namijenjen za interne svrhe, ali slučajno objavljen u javnosti, govorio je o moći Amazona koji koristi SOA. Ovo je odlično štivo, pa ga svakako cijenite, ali glavne teze Bezosovog pisma sadržane su u sljedećim citatima iz posta:

1) Svi timovi od sada pružaju svoje podatke i funkcionalnost putem servisnih interfejsa.

2) Timovi moraju međusobno komunicirati putem ovih interfejsa.

3) Drugi oblici međuprocesne komunikacije su zabranjeni: bez direktnih veza, bez direktnog čitanja podataka druge komande, bez modela dijeljene memorije, bez backdoor-a i slično. Jedini dozvoljeni način komunikacije je pristup interfejsu usluga preko mreže.

4) Nije bitno koju tehnologiju koriste. HTTP, Corba, Pubsub, vlasnički protokoli - nema razlike. Bezosa nije briga.

5) Svi servisni interfejsi, bez izuzetka, moraju biti inicijalno dizajnirani sa mogućnošću upravljanja izvana. Odnosno, tim mora planirati i dizajnirati kako bi mogao pružiti interfejs programerima izvan kompanije. Nema izuzetaka.

6) Svako ko je ignorisao ove uslove biće otpušten.

SOA je ozbiljan posao. Nesumnjivo postoje mnogi problemi koji se javljaju prilikom upotrebe - pogledajte ovaj post na Amazonu "naučene lekcije" - ali ima nevjerovatan broj prednosti.

Vjerovatno nećete previše brinuti o SOA-i dok sami kreirate "igračke" aplikacije, ali ovo pitanje će se svakako pojaviti kada počnete raditi u IT kompaniji, pa je upoznavanje s njom dobra praksa.

Vaš cilj

1. Pročitajte 7. odjeljak Rails vodiča za kontrolere da naučite o prikazivanju JSON-a i XML-a.
2. Oni su opcioni (jer idu malo dalje od onoga što trenutno imamo), ali ako ste zainteresovani, pogledajte Railscasts u odjeljku Dodatni resursi na dnu vodiča kako biste saznali više o prednostima API-ja.

Zaključak

Bliže ćemo sarađivati ​​sa vašom aplikacijom kao API tokom kursa Javascript. U ovom kursu ćete kreirati nekoliko full stack aplikacija koje koriste AJAX pozive za bolje korisničko iskustvo, što u stvari uključuje prikazivanje XML ili JSON podataka umjesto pune HTML stranice. Zatim ćete kreirati nekoliko jednostraničnih Javascript aplikacija koje se oslanjaju na API koji obezbeđuje vaša Rails aplikacija da bi dobili sve potrebne podatke iz baze podataka i na drugi način pokrenuli na strani klijenta (u pretraživaču).

Najbolji način za razumijevanje API-ja je kreiranje i interakcija s njim, na što ćemo se fokusirati u našim projektima.

U ovom postu pokušao sam prikupiti informacije koje mogu biti korisne testerima koji žele znati šta je API. Nadam se da će ljudi koji imaju iskustvo u API testiranju pronaći nešto korisno za sebe. Pa, ili vam barem pomoći da pronađete greške u mom članku :)
Šta je API

API (Application Programming Interface) je skup gotovih klasa, procedura, funkcija, struktura i konstanti koje daje aplikacija (biblioteka, servis) za upotrebu u eksternim softverskim proizvodima (Wikipedia).

Po našim vlastitim riječima, API nam pruža mogućnost da koristimo tuđi rad u vlastite svrhe. Prvi put sam naišao na API koristeći Windows API kao primjer. Ovo je skup funkcija koje može koristiti bilo koja aplikacija koja radi na datom OS-u. Na primjer, može koristiti standardne funkcije za renderiranje sučelja.

Moderni API-ji često imaju oblik web servisa koji pružaju informacije korisnicima (i ljudima i drugim web servisima). Obično su postupak razmjene informacija i format prijenosa podataka strukturirani tako da obje strane znaju kako međusobno komunicirati.

Na stranici https://dev.hh.ru/ (tačnije, https://github.com/hhru/api/blob/master/docs/general.md) možete pronaći opis kako HeadHunter API klijenti a usluge međusobno komuniciraju. Na primjer, citat sa stranice:

• Sav API radi preko HTTPS protokola.
• Autorizacija se vrši korištenjem OAuth2 protokola.
• Svi podaci su dostupni samo u JSON formatu.
• Osnovni URL - https://api.hh.ru/
• Datumi su formatirani prema ISO 8601: GGGG-MM-DDThh: mm: ss ± hhmm

Možete pročitati HH API za dobar primjer prilagođene dokumentacije.

Formati prijenosa podataka

Postoji mnogo formata podataka koje korisnici koriste za interakciju s API-jem. Na primjer, dobro poznati XML. Ili je JSON lagan i nekompliciran format koji izgleda ovako:

("id": "0001", "type": "krofna", "name": "Torta", "image": ("url": "images / 0001.jpg", "width": 200, "visina ": 200)) P o ss Na linkovima ispod možete vidjeti odgovore koji dolaze MediaWikiAPI , u različitim formatima :

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 ( pažljivo, desiće se sa zamahom fajl)

Http r lagols

Obično P Prilikom pristupa web API-jukoristeći postoje HTTP zahtjevi . DakleMoram da kažem bar ukratko o tome standardne metode, koje mogu biti sadržane u HTTP zahtjev . Ove metode nazivaju se i HTTP glagoli :

• GET. Vjerovatno najpopularniji tip zahtjev. Koristi se za primanje ili čitanje podataka.
• STAVITI. Custom n oh i spo koristi se za ažuriranje resursa .
• POŠTA. Obično se koristi za kreiranje novog resursa.
• IZBRIŠI. Briše podatke.
• Ostalo

Ako želimo da dobijemo informacije o nekom resursu,Čiji URI http://www.example.com/customers/12345 , možemo poslati zahtjev:
NABAVITE http://www.example.com/customers/12345

Ako želimo ažurirati resurs - možemo poslati PUT zahtjev:
PUT http://www.example.com/customers/12345/orders/98765

Uobičajeni GET zahtjevi se mogu slati putem web pretraživača. Za slanje drugih vrsta zahtjeva, možda će biti potrebni jezici za skriptiranje ili posebni alati (više o tome u nastavku).

O HTTP-u metode se mogu detaljnije pročitati at na W iki.

HTTP na ode odgovora

Server može slati različite kodove kao odgovor na zahtjeve korisnika. To mogu biti kodovi grešaka ili jednostavno kodovi koji informišu korisnike o stanju servera. Detaljan opis možete pronaći, opet, na wikiju.

Najpoznatiji kodovi su 4xx (problemi na strani klijenta) i 5xx (problemi na strani servera). Programeri API-ja sami odlučuju koje kodove će vratiti u datoj situaciji. Na primjer, API web stranice Odnoklassniki vraća kodove, čiji se opis može naći na https://apiok.ru/wiki/pages/viewpage.action?pageId=77824003.

Osim toga, savjetujem vam da poslušate pjesmu Request Response - jednostavna je i jasna o kodovima vraćenim u HTTP zahtjevima (pazite, repchik :)).

REST API

REST API je ideologija posta rojenje API, što je skraćenica zaReprezentativni državni transfer API. Zasnovan je na sljedećim principima koje je formulirao njegov tvorac Autor Roy Fielding:

1. Arhitektura klijent-server
2. Server bez državljanstva
3. Mogućnost keširanja
4. Višeslojna struktura
5. Unified interface
6. Kod na zahtjev

Neću ulaziti u detalje, mogu savjetovati one koji žele da čitaju na temu