Pješčanik

čelik, nerc, govedina, papir 26. studenog 2012. u 13:59

Što je API

Lijep pozdrav!
U ovom članku ćemo pogledati što je API, gdje, kako i za što se koristi. Također ćemo pogledati kako se API može koristiti u vašem web razvoju i kako može olakšati život web programeru.

Pa počnimo s definicijom. API (Application Programming Interface) je programsko sučelje, sučelje za izradu aplikacija. U razumljivijem jeziku, API je gotov kod koji pojednostavljuje život programera. API je stvoren kako bi programer stvarno mogao olakšati zadatak pisanja ove ili one aplikacije korištenjem gotovog koda (na primjer, funkcija). Dobro poznati jQuery napisan u JavaScriptu također je vrsta API-ja. Ako uzmemo u obzir ovaj primjer, jQuery znatno olakšava pisanje koda. Ono što se može učiniti u 30 redaka s uobičajenim JavaScript alatima, napisano je kroz jQuery u 5-6. Ako uzmemo u obzir API općenito, onda možete pronaći puno usluga koje predstavljaju razvojna rješenja. Danas je najpoznatiji servis code.google.com koji nudi pedesetak različitih API-ja! Ovo je sučelje za izradu Android aplikacija, te raznih API-ja za rad s AJAX-om, te raznih API-ja aplikacija koji se lako mogu prilagoditi vašim željama.

Uostalom, ima li smisla pisati kod vlastitim rukama? Zašto raditi na već stvorenom? Ima li smisla odbiti besplatna rješenja (i zapravo besplatnu pomoć) u web razvoju? Ako ste na sva ova pitanja odgovorili "NE", smatrajte da razumijete bit API-ja.

Ali također želim pojasniti. Programeri početnici NE bi trebali koristiti polugotova rješenja jer se u budućnosti neće nositi sa pravim zadatkom. Stoga, ako ste web programer početnik, nemojte koristiti polugotove proizvode! Naučite razmišljati svojom glavom, gradite razne algoritme kako biste razumjeli bit programiranja. Također kažem, već se obraćam svima, da API nije gotovo rješenje, on je okruženje, sučelje za izradu vlastitih projekata. Ne jedete valjda smrznute mesne okruglice iz trgovine? Prvo ih ispečete, zar ne? Ova analogija vrlo jasno prikazuje bit API-ja.

Općenito, rekao sam što je API, gdje i kako se koristi, što je najvažnije, za što. Želim vam ugodno proučavanje web programiranja i shvaćanje njegovih većih dubina!

Nema oznaka

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

Windows API - skup funkcija operacijskog sustava

Skraćenica API mnogim se programerima početnicima čini vrlo tajanstvenom i čak zastrašujućom. Zapravo, programsko sučelje aplikacije (API) samo je neki gotov skup funkcija koje razvijači aplikacija mogu koristiti. Općenito, ovaj koncept je ekvivalent onome što se prije češće nazivalo knjižnicom potprograma. Međutim, API se obično shvaća kao posebna kategorija takvih knjižnica.

Tijekom razvoja gotovo svake prilično složene aplikacije (MyApplication), formira se skup specifičnih internih funkcija za krajnjeg korisnika, koji se koristi za implementaciju ovog određenog programa, koji se naziva MyApplication API. Međutim, često se ispostavi da se te funkcije mogu učinkovito koristiti za stvaranje drugih aplikacija, uključujući druge programere. U ovom slučaju, autori, na temelju strategije promicanja svog proizvoda, moraju odlučiti hoće li otvoriti pristup ovom skupu za vanjske korisnike ili ne? Ako je odgovor potvrdan, u opisu softverskog paketa izraz se pojavljuje kao pozitivna karakteristika: “Paket uključuje otvoreni skup API funkcija” (ali ponekad za dodatni novac).

Dakle, najčešće se API odnosi na skup funkcija koje su dio jedne aplikacije, ali su u isto vrijeme dostupne za korištenje u drugim programima. Na primjer, Excel, osim sučelja za krajnjeg korisnika, ima skup Excel API funkcija koje se mogu koristiti, posebice, pri izradi aplikacija pomoću VB-a.

Sukladno tome, Windows API je skup funkcija koji je dio samog operativnog sustava, a istovremeno je dostupan bilo kojoj drugoj aplikaciji, uključujući i one napisane pomoću VB-a. U tom smislu sasvim je opravdana analogija s BIOS/DOS skupom prekida sustava koji je zapravo DOS API.

Razlika je u tome što je sastav Windows API funkcija, s jedne strane, mnogo širi u usporedbi s DOS-om, as druge strane ne uključuje mnoge alate za izravno upravljanje računalnim resursima koji su bili dostupni programera u prethodnom OS-u. Osim toga, pristup Windows API-ju izvodi se pomoću običnih proceduralnih poziva, a DOS funkcije se pozivaju putem posebne strojne instrukcije procesora, koja se naziva Interrupt ("prekid").

Zašto vam je potreban Win API za VB programere

Unatoč činjenici da VB ima veliku raznolikost funkcija, u procesu više ili manje ozbiljnog razvoja, ispada da njihove mogućnosti često nisu dovoljne za rješavanje potrebnih zadataka. U isto vrijeme, programeri početnici često se počinju žaliti na nedostatke VB-a i razmišljaju o promjeni alata, ne sumnjajući da njihovo računalo ima ogroman skup alata i samo ih trebate znati koristiti.

Kada se upoznate s Win API-jem, ispada da mnoge ugrađene VB funkcije nisu ništa drugo nego poziv 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 prijeći na korištenje API-ja, jer to ponekad može značajno poboljšati performanse (osobito zbog nepostojanja nepotrebnih konverzija 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, CreateDirectory API moćniji je od ugrađene VB MkDir izjave.
3. Ogroman broj API funkcija uopće nema analoga u trenutnoj verziji VB jezika. Na primjer, ne možete izbrisati imenik koristeći VB - morate koristiti funkciju DeleteDirectory da to učinite.

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 niza jezičnih ograničenja, na primjer, zbog nedostatka mogućnosti rada s memorijskim adresama. Ali u nekim slučajevima mogu pomoći netrivijalne tehnike programiranja (osobito u slučaju istih adresa).

Autorovo osobno stajalište je da umjesto širenja s verzije na verziju ugrađenih funkcija VB-a treba dati dobar opis najpopularnijih API funkcija. Istodobno, želio bih savjetovati programerima da ne čekaju novu verziju alata s naprednim značajkama, već da pažljivo prouče sastav postojećeg Win API-ja - vjerojatno je da bi se značajke koje su vam potrebne mogle implementirati već u VB 1.0 verzija izdanja iz 1991.

Kako naučiti Win API

Ovo nije tako jednostavno pitanje, s obzirom da se broj Win32 API funkcija procjenjuje na oko 10.000 (nitko ne zna točan broj, čak ni Microsoft).

VB (verzije 4-6) uključuje datoteku s opisom Win API deklaracija - WIN32API.TXT (više o njegovoj upotrebi kasnije). Ali, kao prvo, može se koristiti za dobivanje informacija o svrsi određene funkcije i njezinim parametrima samo prema korištenim mnemoničkim imenima, i kao drugo, popis funkcija u ovoj datoteci je daleko od potpune. Jedno vrijeme (prije sedam godina) VB 3.0 imao je posebne datoteke pomoći koje su opisivale funkcije Win16 API-ja. Međutim, već u v.4.0 ove korisne informacije s praktičnim sučeljem su nestale.

Sveobuhvatne informacije o Win32 API-ju mogu se pronaći u pomoći za Platform Software Development Kit, koja je uključena na CD-ove MSDN Library uključene u VB 5.0 i 6.0 Enterprise Edition i Office 2000 Developer Edition. Međutim, tamo nije lako pronaći potrebne informacije i razumjeti ih. Da ne spominjemo činjenicu da su svi opisi tamo dani u odnosu na C jezik.

Svjetski priznati vodič za učenje API programiranja u VB okruženju su knjige poznatog američkog stručnjaka Daniela Applemana. Njegova serija Dan Appleman's Visual Basic Programmer's Guide to the Windows API (za Win16, Win32, u odnosu na različite verzije VB) dosljedno je bila bestseler za VB programere od 1993. godine. Dan Appleman's VB 5.0 Programmer's Guide to the Win32 API, objavljen 1997. godine, donio je autoru iz SAD-a prijatelj koji ga je pronašao u prvoj knjižari u malom provincijskom gradu.

Ova knjiga ima više od 1500 stranica i uključuje opće tehnike programiranja VB API-ja, kao i više od 900 funkcija. Priloženi CD-ROM sadrži puni tekst knjige i sve primjere programiranja, kao i nekoliko dodatnih poglavlja koja nisu uključena u tiskanu verziju. Godine 1999. Dan Appleman izdao je novu knjigu, Dan Appleman's Win32 API Puzzle Book and Tutorial for Visual Basic Programmers, koja uključuje informacije o još 7600 funkcija (iako ne tako opsežne).

Win API i biblioteka dinamičkih veza (DLL)

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

U ovom slučaju, pod DLL-om mislimo na tradicionalnu varijantu binarnih dinamičkih knjižnica, koje omogućuju izravan pristup aplikacija potrebnim procedurama - potprogramima ili funkcijama (slično kao što se događa pri pozivanju procedura unutar VB projekta). Takve se biblioteke mogu stvoriti pomoću različitih alata: VC ++, Delphi, Fortran, osim VB (vidjet ćemo što će se pojaviti u verziji 7.0) - potonji može stvoriti samo ActiveX DLL-ove, kojima se pristupa putem OLE Automation sučelja.

Tipično, datoteke biblioteke dinamičkog povezivanja imaju ekstenziju .DLL, ali to uopće nije potrebno (za Win16 često se koristila ekstenzija .EXE); Upravljački programi vanjskih uređaja identificirani su s .DRV.

Kao što smo već primijetili, prilično je teško odrediti točan broj Windows API-ja i datoteka koje ih sadrže, ali svi se nalaze u direktoriju sustava. S tim u vezi, bolje je izdvojiti sastav biblioteka uključenih u jezgru operativnog sustava, te glavne biblioteke s ključnim dodatnim funkcijama.

A sada nekoliko savjeta.

Savjet 1: provjerite je li vaš DL oglas ispravno formatiran L-postupci

Sam poziv DLL procedurama u programu izgleda potpuno isto kao i "običnim" Visual Basic procedurama, na primjer:

Poziv DllName([popis argumenata])

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

Deklarirajte SubLibProcedureName _ “LibraryName” _ [([ArgumentList])]

Deklarirajte funkciju FunctionName _ Lib "LibraryName" _ [([ArgumentList])]

Ovdje su opcijski elementi operatora dani u uglatim zagradama, izrazne varijable u kurzivu, ostale riječi su ključne riječi. Sustav pomoći ima prilično dobar opis sintakse operatora, tako da ćemo za sada istaknuti samo nekoliko stvari.

Deklaracije vanjskih funkcija moraju se staviti u odjeljak Opće deklaracije modula. Ako ga postavite u modul obrasca, tada morate navesti ključnu riječ Private (ova će deklaracija biti dostupna samo unutar ovog modula) - ovo je ograničenje za sve postupke modula obrasca.

Skup Win32 API implementiran je samo kao funkcije (Win16 API je imao mnogo podrutina). Uglavnom se radi o funkcijama tipa Long koje najčešće vraćaju kod završetka operacije.

Naredba Declare pojavila se u MS Basicu još u doba DOS-a, a također se koristila za deklariranje internih procedura projekta. U Visual Basicu to nije potrebno jer je deklaracija internih procedura automatski njihova pod ili deklaracija funkcije. U odnosu na Basic/DOS, u novom opisu obavezno je navesti naziv bibliotečke datoteke u kojoj se nalazi tražena procedura. Wip API biblioteke nalaze se u direktoriju sustava Windows, tako da je dovoljno navesti samo naziv datoteke. Ako pristupate DLL-u koji se nalazi na proizvoljnoj lokaciji, morate zapisati puni put do te datoteke.

Opis naredbe Declare obično zauzima dosta prostora i ne stane u jedan red u prozoru koda. Stoga preporučujemo da slijedite neku specifičnu shemu prijelaza redaka kada pišete aplikacije, na primjer:

Deklarirajte funkciju GetTempPath _ Lib "kernel32" Alias ​​​​"GetTempPathA" _ (ByVal nBufferLength As Long, _ ByVal lpBuffer As String) As Long

U ovom su slučaju svi glavni elementi opisa odvojeni u različite retke i stoga se dobro čitaju.

Savjet 2: Budite posebno oprezni kada radite s DLL funkcijama

Korištenje Win API-ja i raznih DLL funkcija značajno proširuje funkcionalnost VB-a i često poboljšava performanse programa. Međutim, isplativost za to je rizik smanjenja pouzdanosti aplikacije, posebno u procesu otklanjanja pogrešaka.

Jedna od najvažnijih prednosti VB okruženja je pouzdanost procesa programiranja: radeći pod kontrolom tumača, programski kod teoretski ne može poremetiti rad Windowsa i samog VB-a. Programer možda neće biti jako pažljiv na ispravnost prosljeđivanja parametara pozvanim funkcijama - takve će pogreške lako otkriti sam tumač bilo u procesu prevođenja koda ili tijekom njegovog izvođenja. U najneugodnijem slučaju, način obrade jednostavno će se prekinuti, uz naznaku gdje i zašto je došlo do pogreške.

Izravno korištenje Windows API funkcija ili drugih DLL-ova uklanja takvu kontrolu nad prijenosom podataka i izvršavanjem koda izvan VB okruženja. Stoga pogreška u pristupu vanjskim funkcijama može dovesti do neoperabilnosti i VB-a i operativnog sustava. To je osobito istinito u fazi razvoja programa, kada je prisutnost pogrešaka sasvim prirodna. Dakle, primjenom širih mogućnosti funkcija baznog sloja sustava, programer preuzima odgovornost za ispravnost njihove primjene.

Problem je pogoršan činjenicom da različiti programski jezici koriste različite načine prosljeđivanja parametara između procedura. (Točnije, različite metode prosljeđivanja koriste se prema zadanim postavkama, budući da mnogi jezici mogu podržavati više metoda.) Win API-ji su implementirani u C/C++ i koriste C/C++ konvencije prosljeđivanja parametara, koje se razlikuju od onoga za što se koristi VB .

S tim u vezi, valja napomenuti da je pojava analoga API funkcija ugrađenih u VB opravdana upravo prilagodbom potonjeg VB sintaksi i implementacijom odgovarajućeg mehanizma kontrole razmjene podataka. Također imajte na umu da je u fazi eksperimentalnog otklanjanja pogrešaka aplikacije, pri stvaranju izvršnog modula, bolje koristiti opciju kompilacije P-koda umjesto izvornog koda (strojnog koda). U prvom slučaju, program će se izvoditi pod kontrolom tumača - sporiji od strojnog koda, ali pouzdaniji u smislu mogućih pogrešnih učinaka na operativni sustav i pružajući prikladniji način za otkrivanje mogućih pogrešaka.

Savjet 3: Deset savjeta Dana Applemana za pouzdano API programiranje u VB-u

Korištenje API funkcije zahtijeva pažljivije programiranje, korištenje nekih od nepoznatijih metoda pozivanja procedura (u usporedbi s VB). Nastavit ćemo se baviti ovim problemima u nastavku. A sada je sažetak savjeta Dana Applemana o ovoj temi (njihova prva verzija pojavila se još 1993. godine), uz neke naše dodatke i komentare.

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

Ovi primjeri pokazuju učinak naredbe ByVal na prosljeđivanje parametara

Vrsta parametra	Uz ByVal	Bez ByVal-a
Cijeli broj	16-bitni cijeli broj se gura na stog.	32-bitna adresa 16-bitnog cijelog broja gura se na stog.
dugo	32-bitni cijeli broj se gura na stog.	32-bitna adresa 32-bitnog cijelog broja gura se na stog.
Niz	Niz se pretvara u format koji se koristi u C-u (podaci i završni nulti bajt). 32-bitna adresa novog retka gura se na stog	VB deskriptor niza se gura na stog. (Sam Windows API nikada ne koristi takve ručke i prepoznaju se samo u DLL-ovima implementiranim posebno za VB.)

Ovdje treba podsjetiti da se prijenos parametara u bilo kojem programskom sustavu, uključujući VB, izvodi na dva glavna načina: referencom (ByRef) ili vrijednosti (ByVal). U prvom slučaju prosljeđuje se adresa varijable (ova se opcija koristi u VB prema zadanim postavkama), u drugom - njezina vrijednost. Temeljna razlika leži u činjenici da se uz pomoć reference promijenjena vrijednost proslijeđenog parametra vraća pozivnom programu.

Da biste to razumjeli, provedite eksperiment pomoću sljedećih programa:

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

Kada pokrenete ovaj primjer, dobit ćete poruku s vrijednošću varijable jednakom 3. Činjenica je da se u ovom slučaju adresa varijable v, fizički stvorena u pozivnom programu, prosljeđuje potprogramu MyProc. Sada promijenite opis postupka u

Sub MyProc (ByVal v As Integer)

Kao rezultat toga, kada pokrenete test, dobit ćete v = 2, jer se samo početna vrijednost varijable prosljeđuje proceduri - rezultat operacija izvedenih na njoj ne vraća se pozivnom programu. Također možete promijeniti način prijenosa po vrijednosti pomoću naredbe Call na sljedeći način:

Sub MyProc (v As Integer) ... Poziv MyProc((v)) ‘ (v) - zagrade označavaju način prijenosa po vrijednosti _.

Međutim, kada se govori o internim VB procedurama, upotreba ključne riječi ByVal u izjavi Call je zabranjena - umjesto nje se koriste zagrade. Ovo ima svoje objašnjenje.

U klasičnom slučaju (C, Fortran, Pascal), razlika između načina rada ByRef i ByVal ovisi o tome što se točno nalazi na stogu za razmjenu podataka - adresa varijable ili njezina vrijednost. Basic povijesno koristi varijantu emulacije softvera ByVal - adresa je uvijek na stogu, ali samo kada se prosljeđuje vrijednost, za to se stvara privremena varijabla. Za razlikovanje ove dvije opcije (klasične i osnovne) koriste se različiti načini opisa ByVal moda. Imajte na umu da emulacija načina rada ByVal u VB-u osigurava veću pouzdanost programa: zbunjujući oblik poziva, programer riskira samo da će ispravljena vrijednost varijable biti vraćena (ili da se neće vratiti) programu koji poziva. U "klasičnoj" verziji, međutim, takva zabuna može dovesti do fatalne pogreške prilikom izvođenja procedure (na primjer, kada se umjesto memorijske adrese koristi vrijednost varijable jednaka, recimo, nuli).

DLL funkcije su implementirane prema "klasičnim" principima i stoga zahtijevaju obvezni opis načina razmjene podataka sa svakim od argumenata. Ovo je svrha deklaracija funkcija kroz Declare opis (točnije, popis proslijeđenih argumenata). Najčešći način za prosljeđivanje parametara Windows API-ju ili DLL funkciji je korištenje ključne riječi ByVal. Štoviše, može se postaviti i u izjavi Declare i izravno prilikom pozivanja funkcije.

Posljedice netočnog prosljeđivanja parametara lako je predvidjeti. Ako primite očito nevažeću adresu, primit ćete poruku GPF (General Protection Fault). Ako funkcija primi vrijednost koja odgovara važećoj adresi, tada će funkcija API-ja ući u tuđe područje (na primjer, u jezgru sustava Windows) sa svim posljedičnim katastrofalnim posljedicama.

2. Provjerite vrstu proslijeđenih parametara. Jednako je važan točan broj i vrsta proslijeđenih parametara. Argumenti deklarirani u Declare moraju odgovarati očekivanim parametrima u API funkciji. Najčešći slučaj pogreške u prosljeđivanju parametara povezan je s razlikom između NULL i niza nulte duljine - zapamtite da to nije ista stvar.

3. Provjerite vrstu povrata.

VB je prilično tolerantan prema neusklađenosti tipa povrata funkcije, jer se numeričke vrijednosti obično vraćaju preko registara, a ne preko stoga. Sljedeća pravila pomoći će odrediti 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 ili kao Sub ili kao funkcija koja vraća vrijednost odgovarajućeg tipa.
• nijedna API funkcija ne vraća brojeve s pomičnim zarezom, ali neki DLL-ovi mogu vratiti takav tip podataka.

4. S velikom pažnjom koristite konstrukciju "As Any". Mnoge Windows API funkcije imaju mogućnost prihvaćanja parametara različitih tipova i korištenja konstrukcije As Any (interpretacija tipa izvodi se ovisno o vrijednosti drugih proslijeđenih parametara).

Dobro rješenje u ovom slučaju može biti korištenje nekoliko aliasa funkcija (Alias) uz izradu dvije ili više deklaracija za istu funkciju, a svaka od deklaracija specificira parametre određenog tipa.

5. Ne zaboravite inicijalizirati nizove. Postoji mnogo funkcija u Win API-ju koje vraćaju informacije učitavanjem podataka u međuspremnike nizova proslijeđenih kao parametar. Čini se da u svom programu sve radite kako treba: ne zaboravite na ByVal, pravilno proslijedite parametre funkciji. Ali Windows ne može provjeriti kolika je veličina memorije dodijeljene nizu. Redak mora biti dovoljno velik da primi sve podatke koji se u njega mogu smjestiti. Odgovornost je VB programera da rezervira međuspremnik ispravne veličine.

Imajte na umu da se na 32-bitnim Windowsima nizovi pretvaraju iz Unicode (dvobajtno kodiranje) u ANSI (jednobajtno) i obrnuto, uzimajući u obzir nacionalne postavke sustava. Stoga, za rezerviranje međuspremnika, ponekad je prikladnije koristiti nizove bajtova umjesto string varijabli. (Više o tome bit će riječi u nastavku.)

Češće nego ne, Win API funkcije vam omogućuju da sami definirate maksimalnu veličinu bloka. Konkretno, ponekad je potrebno pozvati drugu API funkciju koja će "upitati" veličinu bloka. Na primjer, GetWindowTextLength omogućuje određivanje veličine niza koji je potreban za smještaj naslova prozora koji vraća funkcija GetWindowText. U tom slučaju Windows osigurava da ne izađete izvan granica.

6. Svakako koristite Option Explicit.

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

Windows 9x ima poboljšani sustav provjere parametara za većinu API funkcija. Stoga prisutnost pogreške u podacima obično ne uzrokuje fatalnu pogrešku, ali nije tako lako utvrditi što ju je uzrokovalo.

Ovdje vam možemo savjetovati da koristite nekoliko načina za otklanjanje pogrešaka ove vrste pogreške:

• koristite korak-po-korak otklanjanje pogrešaka ili naredbu Debug.Print za pregled svakog sumnjivog poziva API funkcije. Provjerite rezultate ovih poziva kako biste bili sigurni da je sve u redu i da je funkcija lijepo izašla;
• koristite program za ispravljanje pogrešaka u sustavu Windows kao što je CodeView i verziju sustava Windows za ispravljanje pogrešaka (dostupnu u Windows SDK-u). Ovi alati mogu otkriti pogrešku parametra i barem odrediti koja API funkcija uzrokuje pogrešku;
• koristiti dodatne alate trećih strana za provjeru vrsta parametara i valjanosti njihovih vrijednosti. Takvi alati ne samo da mogu pronaći greške u parametrima, već čak i ukazati na liniju VB koda gdje se pogreška dogodila.

Osim toga, potrebno je provjeriti rezultat izvršavanja API funkcije.

8. Zapamtite da cijeli brojevi u VB-u iu Windowsima nisu ista stvar. Prije svega, trebali biste imati na umu da se izraz "Integer" u VB odnosi na 16-bitni broj, u dokumentaciji Win 32 - na 32-bitni broj. Drugo, cijeli brojevi (Integer i Long) u VB su vrijednosti s predznakom (to jest, jedan bit se koristi kao znak, ostali se koriste kao mantisa broja), u sustavu Windows koriste se samo nenegativni brojevi. Ovu okolnost morate imati na umu kada formirate proslijeđeni parametar pomoću aritmetičkih operacija (na primjer, izračunajte adresu zbrajanjem neke baze i pomaka). Standardne VB aritmetičke funkcije nisu prikladne za to. Kako biti u ovom slučaju, razgovarat ćemo zasebno.

9. Obratite veliku pozornost na nazive funkcija. Za razliku od Win16, imena svih Win32 API funkcija osjetljiva su na točnu upotrebu malih i velikih slova (to nije bio slučaj u Win16). Ako negdje koristite malo umjesto velikog slova ili obrnuto, tada željena funkcija neće biti pronađena. Također, pripazite na ispravnu upotrebu sufiksa A ili W u funkcijama koje uzimaju parametre niza. (Više o tome pogledajte u nastavku.)

10. Često spremajte svoj rad. Pogreške povezane s neispravnom upotrebom DLL-a i Win API-ja mogu dovesti do pada VB okruženja, a možda i cijelog operativnog sustava. Trebali biste provjeriti je li kod koji ste napisali prije probnog rada spremljen. Najjednostavnije je postaviti projektne module na automatsko snimanje prije pokretanja projekta u VB.

Nakon što ste pročitali prethodni savjet, mogli biste pomisliti da je korištenje Win API funkcija riskantan posao. To je donekle točno, ali samo u usporedbi sa sigurnim programiranjem koje pruža sam VB. Ali uz njihovu vještu primjenu i poznavanje mogućih zamki, taj je rizik 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-a. U slučaju Win API-ja, sve je puno jednostavnije, budući da je oblik pozivanja ovih funkcija ovdje jasno objedinjen. Pritom treba imati na umu sljedeće ključne točke:

1. Win32 API funkcije su upravo funkcije, odnosno procedure tipa Function (u Win16 API-ju je bilo mnogo Sub rutina). Sve su to funkcije tipa Long, pa su njihovi opisi napisani na sljedeći način: Declare Function name ... As Long ‘ tip funkcije _ eksplicitno je definiran

   Naziv deklaracije funkcije& ' tip funkcije _ definiran je sufiksom

   Pozivanje API funkcije izgleda ovako:

Rezultat& = ImeApi& ([ Popis argumenata]

1. Najčešće je povratna vrijednost funkcije izlazni kod operacije. Štoviše, vrijednost različita od nule u ovom slučaju znači normalan završetak, nula - pogrešku. Obično (ali ne uvijek) možete provjeriti prirodu pogreške pozivanjem funkcije GetLastError. Opis ove funkcije je sljedeći: Declare Function GetLastError& Lib "kernel32" ()

   PAŽNJA! Kada radite u VB-u, najbolje je koristiti svojstvo LastDLLError objekta Err za dobivanje vrijednosti pročišćenog koda pogreške, jer VB ponekad resetira funkciju GetLastError između pozivanja API-ja i nastavka s izvođenjem programa.

   Možete interpretirati kod koji vraća GelLastError koristeći konstante zapisane u datoteci API32.TXT, s imenima koja počinju sufiksom ERROR_.

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

   • ERROR_INVALID_HANDLE = 6& - nevažeća oznaka
   • ERROR_CALL_NOT_IMPLEMENTED = 120& - poziv u sustavu Windows 9x funkcija 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, pogreška je definirana nekom drugom posebnom Return& vrijednošću, najčešće 0 ili -1.

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

   Duge varijable obrađuju najmanje 80% prosljeđivanja argumenata. Imajte na umu da argument stalno 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 niz

   Ova vrsta prijenosa podataka također je prilično česta, i to uz argument stalno Primjenjuje se ByVal. Kada se pozove API funkcija, adresa niza se upisuje na stog, tako da je u ovom slučaju moguća dvosmjerna razmjena podataka. Postoji nekoliko opasnosti kojih morate biti svjesni kada radite sa žicama.

   Prvi je da je memorija rezervirana za string u pozivajućem programu, pa ako će API funkcija ispunjavati nizove, onda prije nego što je pozovete, trebate kreirati niz tražene veličine. Na primjer, funkcija GetWindowsDirectory vraća put do Windows direktorija, koji po definiciji ne smije biti duži od 144 znaka. Prema tome, poziv ove funkcije trebao bi izgledati otprilike ovako:

   WinPath$ = Space$(144) 'reserve string in _ 144 characters Result& = GetWindowsDirectory& (WinTath$, 144) _ 'buffer fill' Result& - stvarni broj znakova u nazivu direktorija _ WinPath$ = Left$(WinPath, Result&)

   Drugi problem je taj što kada se API funkcija pozove, izvorni niz se pretvara u neku njegovu internu reprezentaciju, i obrnuto kada funkcija izađe. Ako se u vrijeme Win16 ova operacija sastojala samo od dodavanja null bajta na kraju niza, tada je s pojavom Win32 tome dodana transformacija dvobajtnog kodiranja Unicode u ANSI i obrnuto. (O tome se detaljno raspravljalo u članku "Značajke rada s varijablama niza u VB-u", ComputerPress 10'99 i 01'2000). Za sada samo imajte na umu da korištenjem ByVal ... As String konstrukta, možete samo razmjenjivati ​​nizove sa znakovnim podacima.

   C) ... Kao bilo koji

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

   D) ... Kao UserDefinedType

   Takva se konstrukcija također često koristi kada je potrebno razmijeniti podatke (općenito u oba smjera) pomoću neke strukture. Ova konstrukcija je zapravo neka vrsta konkretne implementacije oblika prijenosa As Any, samo što je u ovom slučaju funkcija postavljena na fiksnu strukturu.

   Forma strukture podataka definirana je određenom API funkcijom, a odgovornost je programera da je pravilno opiše i rezervira u pozivnom programu. Takav dizajn stalno koristi se bez riječi ByVal, odnosno u ovom slučaju se vrši prosljeđivanje po referenci - adresa varijable se upisuje na stog.

Primjer pozivanja API funkcije

Ilustrirajmo gore navedeno primjerom korištenja dviju korisnih funkcija datoteke - lopen i lread, koje su opisane na sljedeći način:

Deklarirajte funkciju lread Lib “kernel32” _ Alias ​​​​“_lread” (_ ByVal lpFileName As String, _ ByVal wReadWrite As Long) Deklarirajte funkciju lread Lib “kernel32” _ Alias ​​​​“_lread” (_ ByVal hFile As Long, lpBuffer As Any, _ ByVal wBytes As Long) Kao Long

U VB-u, njihovi parnjaci - u ovom slučaju, točni - su operatori Open i Get (za binarni način). Odmah obratimo pozornost na korištenje ključne riječi Alias ​​u deklaraciji funkcije - to je samo slučaj kada ne možete bez nje. Prava imena funkcija u biblioteci počinju podvlakom (tipičan C stil), što nije dopušteno u VB-u.

Operacija otvaranja datoteke može izgledati ovako:

Const INVALID_HANDLE_VALUE = -1 ' nevažeća _ vrijednost rukovanja lpFileName$ = “D:\calc.bas” ' naziv datoteke wReadWrite& = 2 ' način čitanja i pisanja hFile& = lopen(lpFileName$, wReadWrite&) _ ' definiranje rukovanja datotekom Ako je hFile& = INVALID_HANDLE_VALUE Zatim _ ' pogreška pri otvaranju datoteke ' Određivanje koda pogreške CodeError& = Err.LastDllError 'CodeError& = GetLastError _ ' ova konstrukcija ne radi End If

Ovdje morate obratiti pozornost na dvije točke:

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

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

Dim MyVar As Single wBytes = lread (hFile&, MyVar, Len(MyVar) ' čitanje realnog broja, 4 bajta ' wBytes je broj stvarno pročitanih podataka, ' -1 je pogreška... Upišite MyStruct x As Single i As Integer End Type Dim MyVar As MyStruct wBytes = lread (hFile&, MyVar, Len(MyVar)) ' čitanje strukture podataka, 6 bajtova

Imajte na umu da se drugi argument funkcije prosljeđuje po referenci, a ostatak po vrijednosti.

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

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

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

Dim MyArray(1 To 10) As Byte wBytes = lread (hFile&, MyArray(1), _ Len(MyArray(1))* 10) ' čitanje 10 elemenata niza

Određivanjem prvog elementa niza kao argumenta, prosljeđujemo adresu početka memorijskog područja rezerviranog za niz. Očito, bilo koji fragment niza može se popuniti na ovaj način:

WBytes = lread (hFile&, MyArray(4), _ Len(MyArray(1))* 5) ' čitanje elemenata niza od 4. do 8.

Savjet 5: Koristite Alias ​​za prijenose i parametri As Any

Ovdje ćemo na temelju prethodnog primjera otkriti bit četvrtog savjeta Dana Applemana.

Kada radite s funkcijom lread, trebali biste zapamtiti da kada joj pristupate pomoću varijable niza, morate koristiti ključnu riječ ByVal (inače se poruka o ilegalnoj operaciji ne može izbjeći). Radi sigurnosti, možete napraviti dodatni poseban opis iste funkcije za rad samo s varijablama niza:

Deklarirajte funkciju lreadString Lib "kernel32" _ Alias ​​​​"_lread" (_ ByVal hFile As Long, ByVal lpBuffer As String, _ ByVal wBytes As Long) Sve dok

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

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

Čini se da vam sintaksa operatora Declare omogućuje da napravite takvu posebnu deklaraciju za niz:

Deklarirajte funkciju lreadString Lib “kernel32” Alias ​​​​“_lread” (_ ByVal hFile As Long, lpBuffer() As Byte, _ ByVal wBytes As Long) Kao Long

Međutim, žalba

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

neizbježno dovodi do fatalne programske pogreške.

Ovo je nastavak razgovora o osobitostima obrade varijabli niza u Visual Basicu: VB koristi dvobajtno Unicode kodiranje, Win API koristi jednobajtno ANSI kodiranje (štoviše, s formatom usvojenim u C, s nultim bajtom na kraju). Sukladno tome, kada se kao argument koriste string varijable, konverzija iz Unicode u ANSI uvijek se automatski izvodi prilikom pozivanja API funkcije (točnije, DLL funkcije) i obrnuta konverzija prilikom vraćanja.

Zaključak iz ovoga je jednostavan: String varijable se mogu koristiti za razmjenu znakovnih podataka, ali se ne mogu 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 može se koristiti za opisivanje prilagođene strukture. S tim u vezi, treba imati na umu sljedeće:

• Strogo je zabranjeno koristiti sljedeću konstrukciju za pristup Win API-ju: Type MyStruct x As Single s As String ‘ string promjenjive duljine End Type

  U slučaju niza varijabilne duljine, deskriptor niza se prosljeđuje kao dio strukture, sa svim posljedičnim posljedicama u vidu greške u izvršavanju programa.

• Možete koristiti niz fiksne duljine kao element strukture: Type MyStruct x As Single s As String*8 ‘ niz fiksne duljine End Type

U tom slučaju izvodi se odgovarajuća pretvorba kodiranja.

I posljednja napomena: ni u kojem slučaju ne možete koristiti niz varijabli niza (i fiksne i varijabilne duljine) kada pristupate API funkciji. Inače će biti zajamčena pojava "ilegalne operacije".

Vjerojatno ćete imati situaciju u kojoj trebate napisati vlastite DLL funkcije. Potreba za tim će se neizbježno pojaviti ako koristite tehnologiju mješovitog programiranja - korištenje dva ili više programskih jezika za implementaciju jedne aplikacije.

S tim u vezi, napominjemo da je mješovito programiranje prilično uobičajeno za implementaciju prilično složene aplikacije. Doista, svaki jezik (točnije programski sustav temeljen na jeziku) ima svoje prednosti i slabosti, pa je sasvim logično iskoristiti prednosti različitih alata za rješavanje različitih problema. Na primjer, VB - za stvaranje korisničkog sučelja, C - za učinkovit pristup resursima sustava, Fortran - za implementaciju numeričkih algoritama.

Mišljenje autora je sljedeće: svako ozbiljno programiranje zahtijeva da programer posjeduje najmanje dva alata. Naravno, u današnjim uvjetima jasne podjele rada vrlo je teško biti izvrstan poznavatelj čak i dva sustava, pa je logičnija shema “glavni i pomoćni jezici”. Ideja je da čak i mrvica znanja "pomoćnog" jezika (pisanje prilično jednostavnih postupaka) može uvelike poboljšati učinkovitost "glavnog" jezika. Napominjemo da je poznavanje VB-a, barem kao pomoćnog, danas gotovo obavezan uvjet za profesionalnog programera. Usput, u danima DOS-a za svakog programera, uključujuć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 sudionici projekta trebali bi imati ideju o značajkama proceduralnog sučelja na različitim jezicima. I da znate da mnogi programski sustavi (uključujući VB), osim zadanog sučelja, omogućuju korištenje drugih, proširenih metoda za pozivanje procedura, koje omogućuju prilagodbu sučelja drugom jeziku.

Kada proučavate interproceduralno sučelje, trebali biste obratiti pozornost na sljedeće moguće "zamke":

• Različiti jezici mogu koristiti različite konvencije za pisanje identifikatora. Na primjer, uobičajeno je koristiti podvlaku na početku naziva procedure, što nije dopušteno u VB. Ovaj se problem lako rješava korištenjem ključne riječi Alias ​​u izjavi Declare (pogledajte na primjer Savjet 2-3).
• Može se koristiti drugačiji slijed pisanja proslijeđenih argumenata na stog. Na primjer, u doba DOS-a (da budem iskren - ne znam kako to sada izgleda u Windows okruženju), C je pisao argumente s kraja liste, drugi jezici (Fortran, Pascal, Basic ) - s početka.
• Prema zadanim postavkama koriste se različiti principi prosljeđivanja parametara - po referenci ili po vrijednosti.
• Različiti principi pohranjivanja string varijabli. Na primjer, u C-u (kao iu Fortranu i Pascalu) duljina niza određena je nultim bajtom na kraju, dok je u Basicu duljina zapisana eksplicitno u deskriptoru niza. Naravno, morate imati na umu mogućnost korištenja različitih kodiranja znakova.
• Prilikom prijenosa višedimenzionalnih nizova, treba imati na umu 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 stupcima" ”).

Imajući to na umu, mogu se formulirati sljedeće preporuke:

• Koristite najjednostavnije, provjerene načine za prosljeđivanje argumenata DLL funkcijama. Standardi usvojeni za Win API sasvim su prikladni kao model.
• Nikada ne prosljeđujte nizove string varijabli.
• Budite vrlo oprezni pri prosljeđivanju jednostavnih varijabli niza i višedimenzionalnih nizova.
• Svakako na poseban način provjerite funkcionalnost mehanizma za prosljeđivanje argumenata ui iz pozvane procedure. Napišite prilagođeni test za provjeru prijenosa podataka. Zasebno provjerite je li svaki argument ispravno proslijeđen. Na primjer, ako imate postupak s nekoliko argumenata, prvo provjerite ispravnost prosljeđivanja svakog parametra za varijantu s jednim argumentom, a tek onda - za cijeli popis.

Ali što ako je DLL funkcija već napisana, na primjer, u Fortran-u, ali se njezino ulazno sučelje ne uklapa dobro u gore navedene VB standarde? Ovdje postoje dva savjeta. Prvo: napišite testnu DLL funkciju i upotrijebite je da pokušate pronaći pravi poziv iz VB programa metodom pokušaja i pogreške. Drugo: napišite proceduru adaptera u istom Fortranu koja bi omogućila jednostavno sučelje između VB i DLL funkcije s transformacijom jednostavnih struktura podataka u složene (na primjer, pretvaranje višedimenzionalnog niza bajtova u niz nizova).

Dakle: koristite DLL funkcije. Ali budite oprezni...

ComputerPress 9 "2000

API definira funkcionalnost koju program (modul, biblioteka) pruža, dok vam API omogućuje apstrahiranje od toga kako je točno ta funkcionalnost implementirana.

Ako se program (modul, biblioteka) smatra crnom kutijom, onda je API skup "ručkica" koje su dostupne korisniku ove kutije, a koje on može okretati i povlačiti.

Softverske komponente međusobno komuniciraju putem API-ja. U tom slučaju komponente obično tvore hijerarhiju - komponente visoke razine koriste API komponenti niske razine, a one zauzvrat koriste API komponenti još niže razine.

Prema ovom principu, protokoli za prijenos podataka preko . Standardni internetski protokol (OSI mrežni model) sadrži 7 slojeva (od fizičkog sloja prijenosa paketa bitova do sloja aplikacijskih protokola kao što su HTTP i IMAP). Svaki sloj iskorištava funkcionalnost prethodnog podatkovnog sloja i zauzvrat pruža željenu funkcionalnost sljedećem sloju.

Važno je napomenuti da je koncept protokola blizak po značenju konceptu API-ja. Obje su apstrakcije funkcionalnosti, samo u prvom slučaju govorimo o prijenosu podataka, au drugom - o izgradnji računalnih aplikacija.

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

Programsko sučelje aplikacije (API) je softversko sučelje za interakciju između sustava koje vam omogućuje da:

• Dobijte pristup poslovnim uslugama poduzeća
• Razmjena informacija između sustava i aplikacija
• Pojednostavite komunikaciju između tvrtki, partnera, programera i kupaca

Otvorena API strategija

API strategija uključuje:

• Razvoj poslovnih proizvoda na temelju postojećih API-ja
• Pružanje internih usluga programerima
• API modeli monetizacije za izgradnju višekanalne interakcije i povećanje profita

Implementacija Open API koncepta pomaže transformirati poslovanje, ugraditi ga u fleksibilan projektni ekosustav tržišnih igrača, stvoriti uvjete za stalno generiranje novih ideja i stvaranje dodatne vrijednosti pri upravljanju korporativnim nizovima podataka.

Tržište integracijskih rješenja razvija se u kontekstu evolucije API-ja - od EDI-ja i SOAP-a do Weba 2.0, čime je započela era javnih API-ja. Broj takvih sučelja u sljedeće 3 godine mogao bi se povećati za više od 50 puta i dosegnuti milijun. To je zbog višekanalnosti: kanali interakcije s kupcima moraju se mijenjati zajedno s njima. Kontinuirani rast broja potrošača i količine podataka doveli su do pojave API ekonomije, koja pomaže u stvaranju inovativnih poslovnih modela temeljenih na otvorenim sučeljima za korištenje imovine i usluga poduzeća.

Potpis funkcije

Potpis funkcije- dio opće deklaracije funkcije, koji omogućuje sredstvima prevođenja da identificiraju funkciju među ostalima. Različiti programski jezici imaju različite ideje o potpisu funkcije, što je također usko povezano s mogućnostima preopterećenja funkcija u tim jezicima.

Ponekad razlikuju pozivni potpis i implementacijski potpis funkcije. Potpis poziva obično se sastavlja prema sintaktičkoj konstrukciji poziva funkcije, uzimajući u obzir potpis opsega ove funkcije, naziv funkcije, slijed stvarnih tipova argumenata u pozivu i vrstu proizlaziti. Signatura implementacije obično uključuje neke elemente iz sintaktičke konstrukcije deklaracije funkcije: specifikator opsega funkcije, njezino ime i slijed tipova formalnih argumenata.

Na primjer, u programskom jeziku C++, prevodilac jedinstveno identificira jednostavnu funkciju po imenu i nizu tipova argumenata, što čini potpis funkcije u ovom jeziku. Ako je funkcija metoda neke klase, tada će i naziv klase sudjelovati u potpisu.

Također treba napomenuti da programer često ima nekoliko različitih API-ja na raspolaganju kako bi postigao isti rezultat. U ovom slučaju, svaki API obično se implementira pomoću API-ja softverskih komponenti niže razine apstrakcije.

Na primjer: da biste vidjeli redak "Hello, world!" sve što trebate učiniti je stvoriti HTML dokument s minimalnim naslovom i jednostavnim tijelom koje sadrži zadani niz. Što se događa kada preglednik otvori ovaj dokument? Program preglednika će proslijediti naziv datoteke (ili već otvoreni deskriptor datoteke) biblioteci koja obrađuje HTML dokumente, koja će zauzvrat, koristeći API operativnog sustava, pročitati ovu datoteku i razumjeti njen uređaj, pozvati operacije poput "očisti prozor”, “piši odabranim fontom Hello, world!”, tijekom ovih operacija grafička primitivna biblioteka će se obratiti biblioteci prozorskog sučelja s odgovarajućim zahtjevima, ova biblioteka će se već obratiti API-ju operativnog sustava sa zahtjevima poput “ stavi me u međuspremnik video kartice ovo".

U isto vrijeme, zapravo postoji nekoliko mogućih alternativnih API-ja na gotovo svakoj razini. Na primjer: mogli bismo napisati izvorni dokument ne u HTML-u, već u LaTeX-u, mogli bismo koristiti bilo koji preglednik za prikaz. Različiti preglednici općenito koriste različite HTML biblioteke, a osim toga, može se (općenito) izgraditi pomoću različitih primitivnih biblioteka i na različitim operativnim sustavima.

Glavne složenosti postojećih slojevitih API sustava su stoga:

• Poteškoće u prijenosu programskog koda s jednog API sustava na drugi (na primjer, pri promjeni OS-a);
• Gubitak funkcionalnosti prilikom prelaska s niže razine na višu. Grubo govoreći, svaki "sloj" API-ja stvoren je da olakša implementaciju nekog standardnog skupa operacija. Ali u isto vrijeme, stvarno postaje teško, ili postaje fundamentalno nemoguće, izvršiti neke druge operacije koje pruža niža razina API-ja.

Osnovni API tipovi

Interni API-ji

• Pristup API-ju ograničen je na interne programere
• Aplikacije su namijenjene zaposlenicima poduzeća

Poslovni pokretači:

• Dosljednost razvoja
• Smanjenje troškova
• Poboljšanje učinkovitosti razvoja

API-ji partnera

• API-ji su dostupni samo ograničenom broju poslovnih partnera
• Aplikacije dizajnirane za krajnje potrošače i poslovne korisnike

Poslovni pokretači:

• Automatizacija procesa razvoja
• Razvoj partnerstva
• Optimizacija procesa interakcije s partnerima

Javni API-ji

Pristup je odobren svim vanjskim programerima. Aplikacije su usmjerene na krajnje korisnike

Poslovni pokretači:

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

Najpoznatiji API-ji

API-ji operativnog sustava

GUI API-ji

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

API-ji mogu biti i zabavni i frustrirajući u isto vrijeme. S jedne strane, interakcijom s drugim aplikacijama možete uvelike povećati doseg publike i "wow efekt" vaše aplikacije. S druge strane, to uključuje čitanje tona dokumentacije, učenje o strategijama provjere autentičnosti i analiziranje neinformativnih (ili čak nedostajućih) poruka o pogreškama.

Prije svega, ako još uvijek ne razumijete u potpunosti što je API (Application Programming Interface), pročitajte Skillcrushovo objašnjenje, a zatim prvi dio ovog članka da nadoknadite.

"API" je nevjerojatno širok koncept - svaki put kada vaša aplikacija "razgovara" s drugom aplikacijom, to je putem neke vrste API-ja. Komponente unutar vaše vlastite aplikacije, poput različitih dijelova Railsa, također međusobno komuniciraju putem API-ja. One su više-manje neovisne pod-aplikacije koje prosljeđuju podatke koje su im potrebne za obavljanje vlastitih specifičnih zadataka. U svijetu aplikacija sve je API!

Kada izradite aplikacije s dinamičnijom front-end funkcionalnošću (i Javascript aplikacije s jednom stranom i jednostavne aplikacije s odvojenim AJAX pozivima), one će komunicirati s Rails pozadinom putem vašeg vlastitog API-ja, što je zapravo samo dodatna linija ili tri koda ., govoreći vašim kontrolerima kako poslužiti JSON ili XML umjesto HTML-a.

U ovom ćete vodiču naučiti kako izraditi vlastiti API. U narednim lekcijama pokrit ćemo kako komunicirati s API-jima drugih aplikacija. Lekcije bi trebale biti dobra odskočna daska za učenje o ovoj temi, ali malo je vjerojatno da će moći u potpunosti pokriti sve slučajeve. Velik dio rada s API-jima je mogućnost čitanja njihove dokumentacije i otkrivanja što žele od vas.

Točke za razmišljanje

Pregledajte pitanja i provjerite znate li odgovore. Provjerite se ponovno nakon izvršenja zadatka.

• Kako Rails razumije koju vrstu datoteke očekujete kao odgovor kada pošaljete HTTP zahtjev.
• Koja je svrha metode #respond_to?
• Kako vratiti korisnički objekt (User) dok navodite atribute koje ne želite uključiti u taj objekt (tj. ne možete samo vratiti User.first)?
• Navedite 2 koraka iza kulisa metode #to_json.
• Kako mogu reći radnji kontrolera da prikazuje samo poruku o pogrešci?
• Kako kreirati vlastitu poruku o pogrešci?
• Zašto ne možete koristiti metode provjere autentičnosti kontrolera temeljene na sesiji ako želite dopustiti programsko povezivanje sa svojim API-jem?
• Što je "uslužno orijentirana arhitektura"?

Osnove API-ja

Vaša Rails aplikacija zapravo je već API, iako je možda ne smatrate API-jem. Web preglednik koji pokreću vaši korisnici također je program, tako da zapravo šalje API zahtjev vašoj Rails aplikaciji kada korisnik otvori novu stranicu. Skloni smo razmišljati na ovaj način jer je iscrtavanje HTML predložaka toliko uobičajen zadatak da ovu funkcionalnost jednostavno kodiramo u naše poslužiteljske programe kao standardnu ​​vrstu odgovora, a sve ostalo smatramo nečim neobičnim.

Međutim, često želite podnijeti zahtjev koji ne zahtijeva da prolazite kroz sve glavobolje korištenja preglednika. Možda vam nije stalo do strukture stranice (HTML), ali zauzvrat želite čiste podatke. Recimo da želite dobiti popis svih korisnika. Možete zatražiti nešto poput http://yourapplication.com/users, što će vjerojatno pokrenuti radnju #index i prikazati popis svih korisnika aplikacije.

Ali zašto se gnjaviti sa svim ovim dodatnim informacijama kada je sve što želite popis korisnika? Najjednostavnija opcija bila bi poslati zahtjev na isti URL, navodeći očekivanje JSON ili XML odgovora zauzvrat. Ako ispravno postavite svoj Rails kontroler, dobit ćete natrag jednostavan JSON objekt polja koji sadrži sve korisnike. Predivno!

Isti princip vrijedi i kada komunicirate s vanjskim API-jem. Recimo da želite dobiti korisnikove nedavne "tweetove" s Twittera. Sve što trebate učiniti je reći svojoj Rails aplikaciji kako da komunicira s Twitter API-jem (tj. autentificirati se), poslati zahtjev i obraditi skup "tvitova" koji će biti vraćeni.

Izrada API-ja

Možda biste željeli učiniti svoju Rails aplikaciju čistim back-end API-jem za front-end web stranice ili jednostavno želite naučiti kako poslati JSON kada front-end to zatraži. Ovaj odjeljak neće pokrivati ​​kako stvoriti potpune RESTful API-je s funkcijom provjere autentičnosti. Ovo je lak uvod u tretiranje vaše aplikacije kao API-ja.

Osnove

Ako želite da vaša Rails aplikacija vraća JSON umjesto HTML-a, morat ćete reći svom kontroleru da to učini. Sjajna je stvar što ista radnja kontrolera može vratiti različite tipove ovisno o tome postavlja li vaš korisnik uobičajeni zahtjev pregledniku ili pristupa API-ju putem naredbenog retka. Ovo određuje koja je vrsta zahtjeva napravljena na temelju ekstenzije tražene datoteke, kao što je example.xml ili example.json.

Možete provjeriti što Rails "misli" o vrsti datoteke koju očekujete provjerom dnevnika poslužitelja:

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

Prvi red vam govori koji je URL zatražen, a drugi kamo je usmjeren i kako Rails to obrađuje. Ako biste koristili ekstenziju .json, to bi izgledalo ovako:

Započeto GET "/posts.json" za 127.0.0.1 u 2013-12-04 12:02:01 -0800 Obrada putem PostsController#index kao JSON

Ako imate pokrenutu testnu aplikaciju, pokušajte zatražiti druge URL-ove. Ako vaš kontroler ne zna kako s njima rukovati, možda ćete dobiti pogrešku, ali biste i dalje trebali moći vidjeti što Rails razumije prema vašim zahtjevima.

Renderiranje JSON ili XML

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

Klasa 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 bloku prosljeđuje objekt formata kojemu možete pridružiti odgovarajući poziv za renderiranje. Ako ne učinite ništa, html će se prikazati pomoću standardnog Rails predloška (app/views/index.html.erb u ovom primjeru).

Funkcija #render dovoljno je pametna da razumije kako prikazati široku paletu formata. Kada mu proslijedite ključ:json, on će pozvati #to_json na vrijednost, u ovom primjeru @users. Ovo će pretvoriti vaše Ruby objekte u JSON nizove, koji će biti proslijeđeni aplikaciji koja zahtijeva.

Ovako dobivate svoj API. Naravno, stvaranje API-ja može biti malo kompliciranije ako želite raditi neke otmjene stvari, ali sve se svodi na osnove.

Određivanje povratnih atributa

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

Prije biste jednostavno nadjačali metodu #to_json svojom verzijom, ali sada to ne morate - zapravo, umjesto toga nadjačavate metodu #as_json. Metoda #as_json koristi se u metodi #to_json, tako da njezina izmjena implicitno mijenja rezultat #to_json, ali na prilično specifičan način.

#to_json radi dvije stvari: pokreće #as_json i dobiva hash atributa koji se prikazuju u JSON. Zatim se renderira u JSON koristeći ActiveSupport::json.encode. Dakle, modificiranjem #as_json precizniji ste u pogledu dijela metode #to_json koji zapravo želite promijeniti.

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

# app/models/user.rb klasa Korisnik< ActiveRecord::Base # Вариант 1: Полное переопределение метода #as_json def as_json(options={}) { :name =>self.name ) # NEMOJTE uključivati ​​polje e-pošte end # Opcija 2: Koristite standardnu ​​metodu #as_json def as_json(options=()) super(only: [:name]) end end

Zatim, u našem kontroleru, sve što trebamo učiniti je renderirati JSON kao normalno (primjer u nastavku uvijek će vratiti JSON, bez obzira je li HTML zahtjev poslan ili ne):

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

Imajte na umu da ne morate sami pozivati ​​#to_json kada koristite #render - on će to učiniti umjesto vas.

Ponekad Heroku može zahtijevati dodatne korake za ispravan prikaz stranica s pogreškama. Izgled. Možda ćete najprije morati ukloniti statične stranice iz imenika aplikacije/javnog imenika.

Osiguranje izvana

Recimo da želite dopustiti pristup API-ju samo ako je korisnik prijavljen. Vaša postojeća provjera autentičnosti kontrolera već obavlja posao - samo provjerite imate li ispravan set #before_action (npr. before_action:require_login). Možda želite funkcionalnost u kojoj i prijavljeni i neprijavljeni korisnici mogu vidjeti stranicu, ali svaki treba vidjeti različite podatke. Ne želite da korisnici koji nisu prijavljeni mogu slati zahtjeve API-ju za dohvaćanje 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 preglednik (na primjer, iz naredbenog retka), ne možete se osloniti na kolačiće preglednika za provjeru autentičnosti. Zbog toga većina API-ja koristi izvorne tokene kao dio postupka provjere autentičnosti. O žetonima ćemo govoriti nešto više u sljedećoj lekciji.

Sljedeći koraci

Sada imate vještine za korištenje vaše Rails aplikacije za posluživanje ne samo HTML-a, već i bilo kojeg drugog formata. Ako želite ići dalje i dopustiti drugim programerima da grade stvari koristeći vašu platformu (na primjer, tako da mogu postavljati programske zahtjeve umjesto da se autentificiraju kao korisnik), morat ćete svoj API sustav učiniti mnogo sigurnijim. Ovdje nećemo pokriti sve, ali pogledajte sljedeće:

• Članak Building Awesome Rails API opisuje mnoge od najboljih pristupa za prelazak s aplikacije igračke na standardne API-je u industriji.

Servisno orijentirana arhitektura

Vrijeme je da predstavimo arhitektonski pristup koji se zove Service-Oriented Architecture (SOA). Osnovna ideja je da će se vaša aplikacija sastojati od mnogih usluga, poput sustava plaćanja, registracije korisnika, modula za preporuke itd. Umjesto da sve to izgradite unutar jedne glavne aplikacije, razbijate podsustave u potpuno neovisne dijelove koji međusobno komuniciraju pomoću internih API-ja.

To je dobro iz mnogo razloga. Osiguravanjem da svaki dio vaše aplikacije ne mari kako drugi dijelovi rade i da samo zna kako tražiti podatke putem svog API-ja, možete izvršiti značajne promjene u kodu usluge i ostatak aplikacije će raditi kao i prije. Jednu uslugu možete potpuno zamijeniti drugom, a sve dok komunicira koristeći iste API metode, ići će vrlo glatko. Možete koristiti vanjske API-je kao dio svoje aplikacije (kao što su procesori plaćanja) umjesto pisanja vlastitih. Možete stvoriti PHP aplikaciju koja je u interakciji s Python aplikacijom koja je u interakciji s Rails aplikacijom, i sve će raditi jer međusobno komuniciraju pomoću API-ja.

Općenito je dobra ideja pokušati svaki dio svoje aplikacije održati što neovisnijim. Koncept SOA-e potiče vas da razmišljate o tome koje točno metode želite izložiti drugim dijelovima svoje aplikacije, a usput će poboljšati vaš kod. Osim toga, pod pretpostavkom da je svaka glavna komponenta vaše aplikacije neovisna, također možete puno lakše izolirati probleme i inteligentnije rješavati pogreške.

Korištenje servisno orijentirane arhitekture za cijelu aplikaciju je poput rastavljanja ogromne, složene Ruby skripte na sjajne klase i metode, samo u većoj mjeri.

Jedan od najpoznatijih slučajeva prelaska na servisno orijentiranu arhitekturu je Amazon.com. Jednog dana 2002. Jeff Bezos otvoreno je izjavio da svi radni timovi moraju prijeći u SOA-u ili dobiti otkaz. ozloglašena post na blogu Googleov zaposlenik, namijenjen za interne potrebe, ali slučajno izložen javnosti, govorio je o moći Amazona koristeći SOA. Ovo je sjajno štivo, stoga ga svakako ocijenite, ali glavne teze Bezosova pisma iznijete su u sljedećim citatima iz objave:

1) Sve naredbe sada pružaju svoje podatke i funkcionalnost putem servisnih sučelja.

2) Timovi moraju međusobno komunicirati putem ovih sučelja.

3) Ostali oblici međuprocesne komunikacije su zabranjeni: nema izravnih poveznica, nema izravnog čitanja podataka iz druge naredbe, nema dijeljenih memorijskih modela, nema "stražnjih vrata" i slično. Jedini dopušteni način komunikacije je pristup sučelju usluge preko mreže.

4) Nije važno koju tehnologiju koriste. HTTP, Corba, Pubsub, izvorni protokoli – nije bitno. Bezosu je svejedno.

5) Sva servisna sučelja, bez iznimke, moraju biti inicijalno dizajnirana s mogućnošću upravljanja izvana. Odnosno, tim mora planirati i dizajnirati kako bi mogao pružiti sučelje programerima izvan tvrtke. Nema izuzetaka.

6) Svatko tko zanemari ove zahtjeve bit će otpušten.

SOA je ozbiljan posao. Naravno, postoji mnogo problema koji se pojavljuju kada ga koristite - pogledajte ovaj post o Amazonovim "naučenim lekcijama" - ali ima nevjerojatnu količinu prednosti.

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

Vaš cilj

1. Pročitajte odjeljak 7 Rails vodiča za kontrolere da biste saznali više o JSON i XML renderiranju.
2. Nije ih potrebno pregledavati (jer idu malo dalje nego što smo trenutno spremni), ali ako ste zainteresirani, pogledajte Railscasts u odjeljku Dodatni resursi na dnu vodiča kako biste saznali više o prednosti API-ja.

Zaključak

Bliže ćemo surađivati ​​s vašom aplikacijom kao API-jem tijekom tečaja Javascript. U ovom tečaju izradit ćete nekoliko full-stack aplikacija koje koriste AJAX pozive za bolje korisničko iskustvo, što zapravo uključuje iscrtavanje XML ili JSON podataka umjesto pune HTML stranice. Zatim ćete stvoriti nekoliko jednostraničkih Javascript aplikacija koje se oslanjaju na API koji pruža vaša Rails aplikacija kako bi dobili sve podatke koji su im potrebni iz baze podataka, a inače se izvode na strani klijenta (u pregledniku).

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

U ovom sam postu pokušao prikupiti informacije koje bi mogle biti korisne testerima koji žele znati što je API. Nadam se da će ljudi koji imaju iskustva u API testiranju također pronaći nešto korisno za sebe. Pa, ili barem pomozite pronaći pogreške u mom članku :)
Što je API

API (Application Programming Interface) - skup gotovih klasa, procedura, funkcija, struktura i konstanti koje daje aplikacija (biblioteka, usluga) za korištenje u vanjskim softverskim proizvodima (Wikipedia).

Drugim riječima, API nam daje priliku da koristimo razvoj drugih ljudi za vlastite potrebe. Prvi put sam naišao na API koristeći Windows API kao primjer. Ovo je skup funkcija koje svaka aplikacija pokrenuta na određenom OS-u može koristiti. Na primjer, može koristiti standardne funkcije za crtanje sučelja.

Moderni API-ji često imaju oblik web usluga koje korisnicima (i ljudima i drugim web uslugama) pružaju neku vrstu informacija. 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/ (točnije, https://github.com/hhru/api/blob/master/docs/general.md) možete pronaći opis kako HeadHunter API klijenti i usluge međusobno djeluju. Na primjer, citat sa stranice:

• Svi API-ji rade preko HTTPS protokola.
• Autorizacija se provodi pomoću OAuth2 protokola.
• Svi podaci dostupni su samo u JSON formatu.
• Osnovni URL — https://api.hh.ru/
• Datumi su oblikovani prema ISO 8601: GGGG-MM-DDThh:mm:ss±hhmm

Možete pročitati HH API - to je dobar primjer korisničke dokumentacije.

Formati prijenosa podataka

Postoje mnogi formati podataka koje korisnici koriste za interakciju s API-jem. Na primjer, dobro poznati XML. Ili JSON - lagani i nekomplicirani format koji izgleda ovako:

( "id": "0001", "type": "krafna", "name": "Torta", "image": ( "url": "images/0001.jpg", "width": 200, "height ": 200) ) P o ss Na donjim poveznicama možete vidjeti odgovore koji dolaze iz 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, dogoditi se uz ljuljanje datoteka)

http g lagos

Obično P Prilikom pristupa web API-jukorištenjem HTTP zahtjevi se šalju . Zatobarem ukratko o standardne metode, koji mogu biti sadržani u HTTP zahtjev . Ove metode nazivaju se i HTTP glagoli :

• DOBITI. Vjerojatno najpopularnija vrsta zahtjev. Koristi se za primanje ili čitanje podataka.
• STAVITI. Uobičajeno n oh i spo Koristi se za ažuriranje resursa .
• POST. Obično se koristi za stvaranje novog resursa.
• IZBRISATI. Briše podatke.
• ostalo

Ako želimo dobiti informacije o izvoru,čiji URI http://www.example.com/customers/12345 , možemo poslati zahtjev:
GET 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čajene GET zahtjeve može poslati web preglednik. Slanje drugih vrsta zahtjeva može zahtijevati skriptne jezike ili posebne alate (više o tome u nastavku).

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

http na odu odgovora

Poslužitelj može slati različite kodove kao odgovor na zahtjeve korisnika. To mogu biti kodovi grešaka ili jednostavno kodovi koji informiraju korisnike o stanju poslužitelja. Detaljan opis može se pronaći, opet, na wikiju.

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

Osim toga, savjetujem vam da poslušate pjesmu Request-response - jednostavno i jasno o kodovima koji se vraćaju u HTTP zahtjevima (pažljivo, repchik :)).

REST API

REST API - ovo je ideologija posta rojenje API, što je kratica zaPrijenos reprezentativnog stanja API. Temelji se na sljedećim načelima koje je formulirao njegov tvorac , Roy Fielding:

1. Arhitektura klijent-poslužitelj
2. Poslužitelj bez stanja
3. mogućnost predmemoriranja
4. Višeslojna struktura
5. Jedno sučelje
6. Šifra na zahtjev

Neću ulaziti u detalje, mogu savjetovati one koji žele čitati o ovoj temi