API(Inglise) Rakenduse programmeerimisliides) - see on rakenduste programmeerimisliides. Konkreetse rakenduse või teenuse API pakub valmisprotseduuride, funktsioonide ja muutujate komplekti, mille abil kolmanda osapoole arendajad saavad selle teenusega töötamiseks luua oma rakendusi ja skripte.

API kaudu töötades saadab rakendus teenusele päringu ja saab vastuse, mis sisaldab nõutud andmeid, olenemata programmeerimiskeelest, milles see loodi.

Mida Beselleri platvormi API võimaldab teil teha?

Beselleri platvormi API loomise eesmärk on pakkuda kolmandate osapoolte rakendustele võimalust suhelda veebipoodide veebisaitide ja andmebaasidega.

Beseller API võimaldab luua oma rakendusi, samuti sünkroonida andmeid äriprotsesside automatiseerimissüsteemidega: raamatupidamine, laohaldus, CRM, meiliuudiskirjad jne.

Veebipoodide omanikel, kes kasutavad kolmandate osapoolte teenuseid ja oma rakendusi, on API kaudu juurdepääs:

Teave tehtud tellimuste kohta

Tellimusteabe töötlemiseks saadaolevad toimingud (meetodid):

1. Tellimuse teabe valimine ID järgi
2. Tellimuse teabe valimine filtri abil
3. Tellimuste arv filtri järgi
4. Looge tellimus
5. Tellimuse kustutamine
6. Tellimuste massiline kustutamine
7. Tellimuste jaoks kõigi saadaolevate olekute valimine
8. Uuenda tellimuse olekut
9. Kommentaari lisamine tellimusele

Tellija teave

1. Tellija lisamine
2. Tellija kustutamine
3. Tellijate massiline kustutamine
4. Tellijaandmete valimine filtri järgi
5. Tellijate arv filtri järgi

Teave registreeritud kasutajate kohta

Tellijate teabe töötlemiseks saadaolevad toimingud (meetodid):

1. Registreeritud kasutajate teabe valimine ID järgi
2. Kõigi registreeritud kasutajate teabe valimine
3. Teabe valimine kõigi kasutaja poolt registreerimisel määratud andmete kohta:
   • Täisnimi;
   • Kontakt e-posti aadress;
   • Kontakttelefon;
   • Määratud tarneaadress: postiindeks, paikkonna nimi, tänava nimi, maja number, hoone number, korteri number, korrus;

Märge! Registreerumisel ei pruugi kasutaja täita kõiki ülaltoodud välju.

API arendusplaanid

Lähitulevikus plaanime avada liidesed, mis toetavad poodide suhtlemist kolmandate osapoolte rakenduste ja teenustega töötamiseks:

1. Kataloogi jaotised.
2. Kaubad.
3. Korv.
4. Allahindlused.
5. Tarneviisid.
6. Makseviisid.

Beselleri platvormi API-ga suhtlemise testimiseks on loodud testpood beseller-api.shop.by.

Testpoodi pääsemiseks peate sisestama sisselogimise ja parooli. Soovi korral saate need oma isiklikult haldurilt.

Enne API-ga interaktsiooni testimist soovitame teil:

1. tee ise mitu tellimust;
2. tellida uudiskiri;
3. vaadake, kuidas kuvatakse kaupluse halduspaneelil teavet esitatud tellimuste ja tellijate kohta.

Poe juhtpaneel on saadaval aadressil: beseller-api.shop.by/manager/. Sisselogimine ja parool juhtpaneeli sisenemisel on sarnased poodi sisenemise sisselogimise ja parooliga.

Kuidas API kaudu oma poega ühendust luua?

Rakenduse ühendamiseks oma poega peate määrama vormi API juurdepääsu URL-i:

http://your_site_address:8082/graphql?token=your_personal_secret_key

Salajase võtme saate nõudmisel oma isiklikult haldurilt.

GraphQL-i funktsioonid ja muutujad Beselleri platvormi API-ga töötamiseks

API-ga ühenduse loomine PHP programmeerimiskeele abil

Beselleri platvormi API-ga töötamise hõlbustamiseks võite kasutada:

1. Meie poolt PHP jaoks välja töötatud klassid.
   1. GraphqlClient- võtab vastu ja edastab andmeid serverisse;
   2. GraphQlHelper- sisaldab juurutatud päringu ja mutatsiooni API-sid;
2. Näited klasside kasutamisest veebipoe andmebaasis valikute ja muudatuste tegemiseks.

Kohaliku keskkonna seadistamine

API-le päringute saatmise ja saadud vastuste selgeks demonstreerimiseks võite kasutada kohalikku keskkonda.

Kohaliku keskkonnana kasutatakse GraphiQL Feeni, see on Google Chrome'i brauseri laiendus, mis võimaldab teil API-le päringuid genereerida.

Pärast rakenduse installimist ilmub teie brauserisse aadressiriba lähedale rakenduse ikoon.

Avage rakendus GraphiQL Feen ja minge vahekaardile "SERVERID", valige POST-i saatmisviis ja seejärel määrake API juurdepääsu URL.

Testi URL-ina tuleks kasutada järgmist aadressi:

Kohalik keskkond on konfigureeritud, saate API-le taotlusi genereerida. Selleks peate avama vahekaardi "PÄRINGUD".

Päringu vormistamine beselleri API-le GraphiQL Feeni abil ja saadud vastus

Ekraanipildi selgitused:

1. Salvestatud päringud
2. Taotluste sisestamise väli
3. Muutuv sisestusväli
4. Vastus saadud
5. Start nupp

Näide taotlusest saada kindlaksmääratud ajavahemiku jooksul esitatud tellimuste loend

päring ($first:Int, $offset:Int, $filter: OrdersFilterType)(
tellimused(esimene:$esimene, nihe:$nihe, filter:$filter)(
kommenteerida
olek(
id
kirjeldus
nimi
}
loomise_kuupäev
update_date
kokku (
järelliide
väärtus
}
makse (
nimi
kirjeldus
maksumus (
järelliide
väärtus
}
}
kohaletoimetamine (
nimi
kirjeldus
maksumus (
järelliide
väärtus
}
}
valuutad (
panga kood
muidugi
järelliide
}
kasutaja andmed(
nimi
kirjeldus
väärtus
}
}
}

Ajavahemiku määramine esitatud tellimuste andmete hankimiseks

{
"filter":(
"date_after": "2017-11-16T00:00:01Z",
"date_before": "2017-11-23T00:00:01Z"
}
}

API vastuse näidis

{{
"andmed":(
"tellimused": [
{
"comment": "Culpa officiis vel ut.",
"create_date": "2017-11-22 16:23:28",
"valuutad": [
{
"bank_code": "BYN",
"kursus": 10000,
"sufiks": "hõõruda."
}
],
"Kohaletoimetamine":(
"kulu": [
{
"sufiks": "hõõruda",
"väärtus": 0
}
],
"description": "Kuller",
"nimi": "kohandatud"
},
"makse":(
"kulu": [
{
"sufiks": "hõõruda",
"väärtus": 0
}
],
"description": "plastkaardid",
"nimi": "kohandatud"
},
"staatus":(
"description": "Uus",
"id": 1,
"nimi": "uus"
},
"kokku": [
{
"sufiks": "hõõruda",
"väärtus": 4450
}
],
"update_date": "2017-11-22 16:23:28",
"kasutaja andmed": [
{
"description": "E-posti aadress",
"nimi": "e-post",
"väärtus": " [e-postiga kaitstud]"
},
{
"description": "Telefon",
"nimi": "telefon",
"value": "784.392.3949 x69329"
},
{
"description": "Aadress",
"nimi": "registreerimine",
"value": "607 Erik Station Suite 057\nReynaberg, WY 83542-0037"
},
{
"description": "Kommentaar",
"nimi": "kommentaar",
"value": "Id nam illo optio."
},
{
"description": "Nimi",
"nimi": "fio",
"väärtus": "Jordi Mann MD"
}
]
}

Liivakast

kõva mees 26. november 2012, kell 13:59

Mis on API

• puutuba*

Tervitused!
Selles artiklis vaatleme, mis on API, kus, kuidas ja milleks seda kasutatakse. Vaatame ka, kuidas saab API-d oma veebiarendustes kasutada ja kuidas see veebiprogrammeerija elu lihtsustada.

Nii et alustame määratlusega. API (Application Programming Interface) on programmeerimisliides, rakenduste loomise liides. Arusaadavamalt öeldes on API valmiskood programmeerija elu hõlbustamiseks. API loodi selleks, et programmeerija saaks valmiskoodi (näiteks funktsioonide) abil tegelikult rakenduse kirjutamise lihtsamaks teha. Tuntud JavaScriptis kirjutatud jQuery on samuti omamoodi API. Kui vaatame seda näidet konkreetselt, muudab jQuery koodi kirjutamise palju lihtsamaks. Mida saab teha tavaliste JavaScripti tööriistadega 30 reas, on jQuery abil kirjas 5-6. Kui vaatame API-sid üldiselt, võime leida palju arenduslahendusi pakkuvaid teenuseid. Tänapäeval on kõige kuulsam teenus code.google.com, mis pakub umbes viiskümmend erinevat API-d! See hõlmab liidest Androidi rakenduste loomiseks, erinevaid API-sid AJAX-iga töötamiseks ja erinevaid rakendusliideseid, mida saab hõlpsasti oma maitse järgi kohandada.

Lõppude lõpuks, kas on mõtet ise koodi kirjutada? Miks töötada juba loodud asjadega? Kas veebiarenduses on mõtet keelduda tasuta lahendustest (ja tegelikult ka tasuta abist)? Kui vastasite kõigile neile küsimustele "EI", siis arvake, et mõistate API olemust.

Aga tahan ka broneerida. Algajad arendajad EI TOHI kasutada poolikuid lahendusi, kuna nad ei tule tulevikus tegeliku probleemiga toime. Seega, kui oled algaja veebiprogrammeerija, siis ära kasuta poolfabrikaate! Õppige oma peaga mõtlema, koostama erinevaid algoritme, et mõista programmeerimise olemust. Ütlen ka juba kõigi poole pöördudes, et API-d ei ole valmislahendused, need on keskkond, liides oma projektide loomiseks. Külmutatud kotlette te ju poest ei söö? Sa prae need enne ära, eks? See analoogia kajastab väga selgelt API olemust.

Üldiselt rääkisin teile, mis on API, kus ja kuidas seda kasutatakse ning mis kõige tähtsam, miks. Soovin teile meeldivat veebiprogrammeerimise õppimist ja selle üha suuremate sügavuste mõistmist!

Sildid: api

Seda artiklit ei kommenteerita, kuna selle autor ei ole veel kogukonna täisliige. Saate autoriga ühendust võtta alles pärast seda, kui ta on kätte saanud

Windows API - operatsioonisüsteemi funktsioonide komplekt

Lühend API tundub paljudele algajatele programmeerijatele väga salapärane ja isegi hirmutav. Tegelikult on rakenduste programmeerimisliides (API) vaid mõni valmis funktsioonide komplekt, mida rakenduste arendajad saavad kasutada. Üldiselt on see kontseptsioon samaväärne sellega, mida varem nimetati sagedamini alamprogrammi raamatukoguks. Kuid API viitab tavaliselt selliste teekide erikategooriale.

Lõppkasutaja jaoks peaaegu iga üsna keeruka rakenduse (MyApplication) väljatöötamise käigus moodustub konkreetsete sisemiste funktsioonide komplekt, mida kasutatakse selle konkreetse programmi rakendamiseks, mida nimetatakse MyApplication API-ks. Sageli aga selgub, et neid funktsioone saab tõhusalt kasutada muude rakenduste loomiseks, sealhulgas teiste programmeerijate poolt. Sel juhul peavad autorid, lähtudes oma toote reklaamimise strateegiast, otsustama küsimuse: kas nad avavad sellele komplektile juurdepääsu välistele kasutajatele või mitte? Kui vastus on jaatav, ilmub tarkvarapaketi kirjelduses positiivse tunnusena (aga mõnikord lisaraha eest) fraas “Paketis on avatud API funktsioonide komplekt”.

Seega viitab API enamasti funktsioonide komplektile, mis on osa ühest rakendusest, kuid on saadaval kasutamiseks ka teistes programmides. Näiteks Excelis on lisaks lõppkasutaja liidesele ka Exceli API funktsioonide komplekt, mida saab kasutada eelkõige VB-ga rakenduste loomisel.

Sellest tulenevalt on Windowsi API funktsioonide komplekt, mis on osa operatsioonisüsteemist ja on samal ajal juurdepääsetav mis tahes muule rakendusele, sealhulgas VB-ga kirjutatud rakendustele. Sellega seoses on analoogia BIOS/DOS-süsteemi katkestuskomplektiga, mis on tegelikult DOS-i API, üsna õigustatud.

Erinevus seisneb selles, et Windows API funktsioonide valik on ühelt poolt DOS-iga võrreldes palju laiem ja teisest küljest ei sisalda see paljusid tööriistu arvutiressursside vahetuks haldamiseks, mis olid programmeerijatele kättesaadavad eelmises versioonis. OS. Lisaks tehakse kõned Windows API-le tavapäraste protseduurikõnede abil ja DOS-i funktsioonide kõned tehakse spetsiaalse protsessori käsklusega Katkesta.

Miks me vajame VB programmeerijate jaoks Win API-d?

Vaatamata sellele, et VB-l on tohutult erinevaid funktsioone, avastatakse rohkem või vähem tõsise arenduse käigus, et nende võimalustest ei piisa sageli vajalike probleemide lahendamiseks. Samal ajal hakkavad algajad programmeerijad sageli kurtma VB puuduste üle ja mõtlevad tööriistade vahetamisele, kahtlustamata, et nende arvutil on tohutult palju tööriistu ja nad peavad lihtsalt teadma, kuidas neid kasutada.

Win API-ga tutvudes avastatakse, et paljud sisseehitatud VB funktsioonid pole muud kui vastavate süsteemiprotseduuride väljakutsed, vaid need on realiseeritud vaid antud keele süntaksi kujul. Seda arvesse võttes määravad API kasutamise vajaduse järgmised valikud:

1. API-funktsioonid, mis on täielikult rakendatud sisseehitatud VB-funktsioonidena. Sellegipoolest on mõnikord sel juhul kasulik üle minna API kasutamisele, kuna see võib mõnikord jõudlust oluliselt parandada (eriti läbitud parameetrite tarbetute teisenduste puudumise tõttu).
2. Sisseehitatud VB-funktsioonid rakendavad ainult vastava API-funktsiooni erijuhtu. See on üsna levinud variant. Näiteks funktsioonil CreateDirectory API on rohkem võimalusi kui sisseehitatud VB MkDir operaatoril.
3. Väga paljudel API-funktsioonidel pole VB keele praeguses versioonis üldse analooge. Näiteks ei saa te VB abil kataloogi kustutada – selleks peate kasutama funktsiooni DeleteDirectory.

Samuti tuleb rõhutada, et mõningaid API funktsioone (nende osakaal Win API-s on väga väike) ei saa VB programmidest välja kutsuda mitmete keelepiirangute tõttu, näiteks mäluaadressidega töötamise võimetuse tõttu. Kuid mõnel juhul võivad abiks olla mittetriviaalsed programmeerimistehnikad (eriti samade aadresside puhul).

Autori isiklik seisukoht on selline - selle asemel, et laiendada VB sisseehitatud funktsioone versioonist versiooni, tuleks sellele anda hea kirjeldus populaarseimatest API funktsioonidest. Samal ajal soovitan arendajatel mitte oodata tööriista uue laiendatud funktsioonidega versiooni ilmumist, vaid vaadata lähemalt olemasoleva Win API koostist - tõenäoliselt on teil vajaminevad võimalused. oleks võinud rakendada juba 1991. aastal välja antud versioonis VB 1.0.

Kuidas õppida Win API-t

See polegi nii lihtne küsimus, kui arvestada, et Win32 API funktsioonide arv on hinnanguliselt umbes 10 tuhat (täpset arvu ei tea keegi, isegi Microsoft mitte).

VB (versioonid 4-6) sisaldab Win API deklaratsioone kirjeldavat faili - WIN32API.TXT (selle kasutamisest räägime hiljem lähemalt). Kuid esiteks saate selle abiga teavet konkreetse funktsiooni eesmärgi ja selle parameetrite kohta ainult kasutatud mnemooniliste nimede abil ja teiseks pole selle faili funktsioonide loend kaugeltki täielik. Omal ajal (seitse aastat tagasi) olid VB 3.0-s spetsiaalsed abifailid, mis kirjeldasid Win16 API funktsioone. Kuid juba v.4.0-s kadus see mugava liidesega kasulik teave.

Põhjalikku teavet Win32 API kohta leiate platvormi tarkvara arenduskomplekti abist, mis sisaldub versioonidega VB 5.0 ja 6.0 Enterprise Edition ning Office 2000 Developer Edition kaasas olevatel MSDN teegi CD-del. Sealt vajaliku info leidmine ja sellest arusaamine pole aga sugugi lihtne. Rääkimata sellest, et kõik seal olevad kirjeldused on antud seoses C-keelega.

Tuntud Ameerika eksperdi Daniel Applemani raamatud on maailmas üldiselt tunnustatud API programmeerimise õppimise eest VB keskkonnas. Tema Dan Applemani Visual Basic Programmer's Guide to Windows API seeria (Win16, Win32 ja erinevate VB versioonide jaoks) on olnud üks enimmüüdud raamatuid VB programmeerijatele alates 1993. aastast. 1997. aastal ilmunud raamatu Dan Appleman’s VB 5.0 Programmer’s Guide to the Win32 API tõi autorile USA-st sõber, kes leidis selle väikese provintsilinna esimesest raamatupoest.

See raamat on üle 1500 lehekülje pikk, hõlmates VB üldisi API programmeerimistehnikaid ja üle 900 funktsiooni. Kaasasolev CD sisaldab raamatu täisteksti ja kõiki programminäiteid ning mitmeid lisapeatükke, mida trükiversioonis ei sisaldu. 1999. aastal andis Dan Appleman välja uue raamatu, Dan Applemani Win32 API mõistatusraamat ja õpetus Visual Basic programmeerijatele, mis sisaldab teavet veel 7600 funktsiooni kohta (kuigi mitte nii ulatuslik).

Win API ja Dynamic Link Library (DLL)

Win API komplekt on rakendatud dünaamiliste DLL-ide kujul. Järgmisena räägime tegelikult DLL-ide kasutamise tehnoloogiast VB keskkonnas Win API-s sisalduvate teekide näitel. Rääkides DLL-idest, tuleb siiski märkida mõned olulised punktid.

Antud juhul peame DLL-i all silmas binaarsete dünaamiliste teekide traditsioonilist versiooni, mis pakuvad rakendustele otsejuurdepääsu vajalikele protseduuridele – alamprogrammidele või funktsioonidele (umbes samamoodi nagu VB projekti sees protseduuride kutsumisel). Selliseid teeke saab luua erinevate tööriistade abil: VC++, Delphi, Fortran, v.a VB (vaatame, mis versioonis 7.0 ilmub) – viimane saab luua ainult ActiveX DLL-e, millele pääseb ligi OLE Automationi liidese kaudu.

Tavaliselt on dünaamilistel teegifailidel laiend .DLL, kuid see pole üldse vajalik (Win16 puhul kasutati sageli laiendit .EXE); välisseadmete draiverid on määratud .DRV abil.

Nagu me juba märkisime, on Windows API funktsioonide ja neid sisaldavate failide täpse arvu kindlaksmääramine üsna keeruline, kuid need kõik asuvad süsteemi kataloogis. Sellega seoses on parem esile tõsta operatsioonisüsteemi tuumas sisalduvate teekide koostis ja peamised lisafunktsioonidega peamised teegid.

Ja nüüd mõned näpunäited.

Nõuanne 1. Veenduge, et teie DL-reklaam on õigesti vormindatud L-protseduurid

DLL-protseduuride kutsumine programmis näeb välja täpselt sama, mis "tavaliste" Visual Basicu protseduuride puhul, näiteks:

Helista DllName([argumentide loend])

Väliste DLL-i funktsioonide (sh Win API) kasutamiseks tuleb need aga programmis deklareerida, kasutades avaldust Declare, mis näeb välja järgmine:

Deklareeri Sub LibProcedureName _ "LibraryName" _ [([Argumentide loend])]

Deklareeri funktsioon FunctionName _ Lib "LibraryName" _ [([Argumentide loend])]

Siin on operaatori valikulised elemendid näidatud nurksulgudes, muutujaväljendid kaldkirjas ja ülejäänud sõnad on võtmesõnad. Abisüsteem kirjeldab operaatori süntaksit üsna hästi, nii et praegu märgime vaid mõned punktid.

Väliste funktsioonide deklaratsioonid tuleks paigutada mooduli jaotisesse Ülddeklaratsioonid. Kui asetate selle vormimoodulisse, siis peate määrama märksõna Privaatne (see deklaratsioon on saadaval ainult selle mooduli sees) - see on kõigi vormimooduli protseduuride piirang.

Win32 API komplekti rakendatakse ainult funktsioonide kujul (Win16 API-l oli palju alamrutiine). Enamasti on need pikka tüüpi funktsioonid, mis enamasti tagastavad toimingu lõpukoodi.

Operaator Declare ilmus MS Basicus juba DOS-i päevil ja seda kasutati ka sisemiste projektiprotseduuride deklareerimiseks. Visual Basicus pole see nõutav, kuna siseprotseduuride deklaratsioon on automaatselt nende alam- või funktsioonideklaratsioon. Võrreldes Basic/DOS-iga peab uus kirjeldus näitama teegi faili nime, kus vajalik protseduur asub. Wip API teegid asuvad Windowsi süsteemikataloogis, seega piisab ainult failinime andmisest. Kui kasutate DLL-i, mis asub juhuslikus kohas, peate selle faili täieliku tee üles kirjutama.

Declare lause kirjeldus võtab tavaliselt üsna palju ruumi ega mahu koodiaknas ühele reale. Seetõttu soovitame taotluste kirjutamisel järgida konkreetset rea katkestamise skeemi, näiteks:

Deklareerige funktsioon GetTempPath _ Lib "kernel32" alias "GetTempPathA" _ (ByVal nBufferLength as Long, _ ByVal lpBuffer kui string) nii pikaks

Sel juhul on kõik kirjelduse põhielemendid paigutatud erinevatele ridadele ja on seetõttu kergesti loetavad.

Nõuanne 2: olge DLL-i funktsioonidega töötades eriti ettevaatlik

Win API ja erinevate DLL-i funktsioonide kasutamine laiendab oluliselt VB funktsionaalsust ja sageli parandab programmi jõudlust. Selle eest makstav hind on aga rakenduse töökindluse vähenemise oht, eriti selle silumise ajal.

VB keskkonna üks olulisemaid eeliseid on programmi arendusprotsessi usaldusväärsus: tõlgi juhtimise all töötades ei saa programmikood teoreetiliselt häirida Windowsi ja VB enda tööd. Programmeerija ei pruugi olla eriti ettevaatlik kutsutud funktsioonidele parameetrite edastamise õigsuse suhtes - tõlk tuvastab sellised vead hõlpsalt kas koodi tõlkimise või selle täitmise ajal. Kõige ebameeldivamal juhul katkestatakse töötlemisrežiim lihtsalt, näidates, kus ja miks viga ilmnes.

Windows API funktsioonide või muude DLL-ide kasutamine eemaldab otseselt sellise kontrolli andmete edastamise ja koodi täitmise protsessi üle väljaspool VB keskkonda. Seetõttu võib viga välistele funktsioonidele juurdepääsul põhjustada nii VB kui ka operatsioonisüsteemi töövõimetuse. See kehtib eriti programmi arendamise etapis, kui vigade esinemine on üsna loomulik. Seega, kasutades süsteemi aluskihi funktsioonide laiemaid võimalusi, võtab programmeerija vastutuse nende õige kasutamise eest.

Probleemi süvendab veelgi asjaolu, et erinevad programmeerimiskeeled kasutavad erinevaid viise parameetrite edastamiseks protseduuride vahel. (Täpsemalt kasutatakse vaikimisi erinevaid edastusmeetodeid, kuna paljud keeled võivad toetada mitut meetodit.) Win API-d on realiseeritud C/C++ keeles ja kasutavad C/C++ parameetrite edastamise konventsioone, mis erinevad tavalisest VB versioonist.

Sellega seoses tuleb märkida, et VB-sse sisseehitatud API funktsioonide analoogide ilmumine on õigustatud just viimaste kohandamisega VB süntaksiga ja sobiva andmevahetuse juhtimismehhanismi rakendamisega. Pangem ka tähele, et rakenduse eksperimentaalse silumise etapis käivitatava mooduli loomisel on parem kasutada Native Code (masinakoodi) asemel P-koodi kompileerimisvalikut. Esimesel juhul töötab programm tõlgi kontrolli all – masinkoodiga võrreldes aeglasem, kuid operatsioonisüsteemi võimaliku eksliku mõju seisukohast töökindlam ning pakkudes mugavamat režiimi võimalike vigade tuvastamiseks.

Vihje 3: Dan Applemani kümme näpunäidet tugeva API programmeerimiseks VB-s

API-funktsiooni kasutamine nõuab hoolikamat programmeerimist, kasutades mõnda vähemtuntud protseduuri kutsumise tehnikat (võrreldes VB-ga). Nende probleemide käsitlemist jätkame ka edaspidi. Ja nüüd esitame Dan Applemani antud teemal sõnastatud nõuannete kokkuvõtte (nende esimene versioon ilmus 1993. aastal) koos mõnede meie täienduste ja kommentaaridega.

1. Pidage meeles ByVal. Kõige levinum viga API- ja DLL-i funktsioonidele juurdepääsul on ByVal märksõna vale kasutamine: nad kas unustavad selle panna või, vastupidi, panevad selle siis, kui seda pole vaja.

Need näited näitavad ByVal operaatori mõju parameetrite edastamisele

Parameetri tüüp	Koos ByValiga	Ilma ByValita
Täisarv	16-bitine täisarv lükatakse virna	16-bitise täisarvu 32-bitine aadress lükatakse virna
Pikk	32-bitine täisarv lükatakse virna	32-bitise täisarvu 32-bitine aadress lükatakse virna
String	String teisendatakse C-s kasutatavasse vormingusse (andmed ja lõpetav nullbait). Reavahetuse 32-bitine aadress lükatakse virna	VB käepide nööri külge lükatakse virna peale. (Selliseid käepidemeid ei kasuta kunagi Windowsi API ise ja neid tunnustatakse ainult spetsiaalselt VB jaoks rakendatud DLL-ides.)

Siinkohal tuleb meenutada, et parameetrite edastamine mis tahes programmeerimissüsteemis, sealhulgas VB-s, toimub kahel põhilisel viisil: viite (ByRef) või väärtuse järgi (ByVal). Esimesel juhul edastatakse muutuja aadress (seda valikut kasutatakse VB-s vaikimisi), teisel - selle väärtus. Põhiline erinevus seisneb selles, et viidet kasutades tagastatakse läbitud parameetri muudetud väärtus kutsuvale programmile.

Selle mõistmiseks viige läbi katse järgmiste programmide abil:

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

Selle näite käivitamisel saate teate, mille muutuja väärtus on võrdne 3-ga. Fakt on see, et sel juhul edastatakse kutsuvas programmis füüsiliselt loodud muutuja v aadress MyProc alamprogrammile. Nüüd muutke protseduuri kirjelduseks

Sub MyProc (ByVal vs täisarv)

Selle tulemusena saad testi sooritamisel v = 2, kuna protseduurile antakse edasi ainult muutuja algväärtus - sellega tehtud toimingute tulemust ei tagastata kutsuvale programmile. Edastusrežiimi väärtuse järgi saab muuta ka kõneoperaatori abil järgmiselt:

Sub MyProc (v As Integer) ... Kutsu MyProc((v)) ‘ (v) - sulud näitavad edastusrežiimi väärtuse järgi.

Sisemiste VB protseduuride juurde pääsemisel on aga kõnelauses ByVal märksõna kasutamine keelatud – selle asemel kasutatakse sulgusid. Sellele on seletus.

Klassikalisel juhul (C, Fortran, Pascal) oleneb ByRef ja ByVal režiimide erinevus sellest, mis täpselt andmevahetuspinu paigutatakse - muutuja aadress või selle väärtus. Basic kasutab ajalooliselt ByVal tarkvara emulatsiooni varianti - pinus on alati aadress olemas, kuid ainult väärtusest mööda minnes luuakse selle jaoks ajutine muutuja. Nende kahe valiku (Classic ja Basic) eristamiseks kasutatakse ByVal-režiimi kirjeldamiseks erinevaid viise. Pange tähele, et ByVal režiimi emuleerimine VB-s tagab programmi suurema töökindluse: viitevormi segamisel riskib programmeerija ainult sellega, et muutuja parandatud väärtus tagastatakse (või ei tagastata) kutsuvale programmile. "Klassikalises" versioonis võib selline segadus protseduuri teostamisel põhjustada saatusliku vea (näiteks kui mäluaadressi asemel kasutatakse muutuja väärtust, mis võrdub näiteks nulliga).

DLL-i funktsioone rakendatakse vastavalt "klassikalistele" põhimõtetele ja seetõttu on vaja iga argumendiga andmete vahetamise kohustuslikku kirjeldust. Seda eesmärki täidavad funktsioonideklaratsioonid Declare kirjelduse kaudu (täpsemalt läbitud argumentide loend). Kõige tavalisem viis parameetrite edastamiseks Windows API funktsioonile või DLL-ile on kasutada märksõna ByVal. Lisaks saab seda määrata nii operaatoris Declare kui ka otse funktsiooni kutsumisel.

Parameetrite vale edastamise tagajärgi on lihtne ennustada. Kui saate ilmselgelt kehtetu aadressi, saate GPF-teate (General Protection Fault). Kui funktsioon saab väärtuse, mis ühtib kehtiva aadressiga, siseneb API-funktsioon võõrasse piirkonda (näiteks Windowsi kernelisse) koos kõigi sellest tulenevate katastroofiliste tagajärgedega.

2. Kontrollige edastatavate parameetrite tüüpi. Sama oluline on edastatud parameetrite õige arv ja tüüp. Declare'is deklareeritud argumendid peavad vastama API funktsiooni eeldatavatele parameetritele. Kõige tavalisem veajuhtum parameetrite edastamisel hõlmab erinevust NULL-i ja nullpikkuse stringi vahel – pidage meeles, et need ei ole samad asjad.

3. Kontrollige tagastustüüpi.

VB on üsna tolerantne funktsiooni tagastamise tüüpi mittevastavuse suhtes, kuna arvväärtused tagastatakse tavaliselt registrite, mitte virna kaudu. Järgmised reeglid aitavad määrata API funktsiooni tagastatud õiget väärtust.

• DLL-i funktsioon, mis ei tagasta väärtust (analoogselt tühimikuga C-s), tuleb deklareerida VB-alamfunktsioonina.
• API funktsiooni, mis tagastab täisarvu väärtuse (täisarv või pikk), saab defineerida kas alam- või funktsioonina, mis tagastab sobivat tüüpi väärtuse.
• Ükski API funktsioon ei tagasta ujukoma numbreid, kuid mõned DLL-id võivad seda tüüpi andmeid tagastada.

4. Kasutage konstruktsiooni "As Any" väga ettevaatlikult. Paljud Windows API funktsioonid suudavad aktsepteerida erinevat tüüpi parameetreid ja kasutada selleks konstruktsiooni As Any (tüübi tõlgendamine toimub sõltuvalt muude edastatud parameetrite väärtusest).

Hea lahendus võib sel juhul olla funktsiooni mitme varjunime (Alias) kasutamine, luues sama funktsiooni jaoks kaks või enam deklaratsiooni, kusjuures iga deklaratsioon määrab konkreetset tüüpi parameetrid.

5. Ärge unustage stringe lähtestada. Win API-s on palju funktsioone, mis tagastavad teavet, laadides andmed parameetrina edastatud stringipuhvritesse. Oma programmis saate näiliselt kõike õigesti teha: ärge unustage ByVali, edastage funktsioonile parameetrid õigesti. Kuid Windows ei saa kontrollida, kui suur on rea jaoks eraldatud mälu maht. Rea suurus peab olema piisavalt suur, et mahutada kõik sinna paigutatavad andmed. Nõutava suurusega puhvri reserveerimise eest vastutab VB programmeerija.

Tuleb märkida, et 32-bitises Windowsis toimub stringide kasutamisel teisendamine Unicode'ist (kahebaidine kodeering) ANSI-le (ühebaidine kodeering) ja tagasi, võttes arvesse riiklikke süsteemiseadeid. Seetõttu on puhvrite reserveerimiseks mõnikord mugavam kasutada stringimuutujate asemel baidimassiivi. (Sellest lähemalt allpool.)

Kõige sagedamini võimaldavad Win API funktsioonid ise määrata maksimaalse ploki suuruse. Eelkõige nõuab see mõnikord mõne muu API funktsiooni kutsumist, mis "ütleb" ploki suuruse. Näiteks võimaldab GetWindowTextLength määrata funktsiooni GetWindowText tagastatud akna pealkirja hoidmiseks vajaliku stringi pikkuse. Sel juhul tagab Windows, et te ei läheks liiale.

6. Kasutage kindlasti valikut Explicit.

7. Kontrollige hoolikalt parameetrite väärtusi ja tagastusväärtusi. VB-l on head tüübikontrolli võimalused. See tähendab, et kui proovite VB-funktsioonile kehtetut parameetrit edastada, on halvim, mis juhtuda saab, et saate VB-lt veateate. Kuid see mehhanism Windows API funktsioonidele juurdepääsul kahjuks ei tööta.

Windows 9x on enamiku API funktsioonide jaoks täiustanud parameetrite kontrollimist. Seetõttu ei põhjusta vea olemasolu andmetes enamasti saatuslikku viga, kuid selle põhjustaja kindlakstegemine polegi nii lihtne.

Siin soovitame seda tüüpi vigade silumiseks kasutada mitut viisi.

• Kasutage iga kahtlase API-funktsiooni kõne kontrollimiseks samm-sammult silumisrežiimi või käsku Debug.Print. Kontrollige nende kõnede tulemusi veendumaks, et kõik on normaalne ja funktsioon on õigesti lõpule viidud;
• kasutage Windowsi silurit (nt CodeView) ja Windowsi silumisversiooni (saadaval Windowsi SDK-s). Need tööriistad suudavad tuvastada parameetrivea ja vähemalt määrata, milline API funktsioon vea põhjustab;
• Parameetritüüpide ja nende väärtuste kehtivuse kontrollimiseks kasutage täiendavaid kolmanda osapoole tööriistu. Sellised tööriistad ei leia mitte ainult parameetrivigu, vaid osutavad isegi VB-koodi reale, kus viga ilmnes.

Lisaks on vaja kontrollida API funktsiooni täitmise tulemust.

8. Pidage meeles, et täisarvud VB-s ja Windowsis ei ole samad. Kõigepealt tasub meeles pidada, et mõiste “Täisarv” tähendab VB-s 16-bitist numbrit, Win 32 dokumentatsioonis aga 32-bitist numbrit. Teiseks on täisarvud (täisarv ja pikk) VB-s märgiga suurused (see tähendab, et märgina kasutatakse ühte numbrit, ülejäänud arvu mantissina), Windowsis kasutatakse ainult mittenegatiivseid arve. Seda asjaolu tuleb meeles pidada, kui moodustate läbitud parameetri aritmeetiliste toimingute abil (näiteks aadressi arvutamisel mõne baasi ja nihke liitmise teel). Tavalised VB aritmeetilised funktsioonid selleks ei sobi. Mida sel juhul teha, arutame eraldi.

9. Pöörake tähelepanu funktsioonide nimedele. Erinevalt Win16-st on kõigi Win32 API funktsioonide nimed tundlikud väike- ja suurtähtede täpse kasutamise suhtes (Win16 puhul see nii ei olnud). Kui kasutate kuskil suurtähtede asemel väiketähti või vastupidi, siis soovitud funktsiooni ei leita. Samuti olge ettevaatlik, et kasutaksite stringiparameetreid kasutavates funktsioonides õigesti järelliidet A või W. (Lisateavet selle kohta leiate allpool.)

10. Salvestage oma tööd sageli. DLL-ide ja Win API-de ebaõige kasutamisega seotud vead võivad viia VB-keskkonna ja võib-olla ka kogu operatsioonisüsteemi hädaolukorra lõpetamiseni. Peaksite veenduma, et teie kirjutatud kood salvestatakse enne testimist. Kõige lihtsam on enne projekti käivitamist VB keskkonnas seadistada projektimoodulite automaatse salvestamise režiim.

Pärast eelnevat nõuannet lugedes võite arvata, et Win API funktsioonide kasutamine on riskantne. Mingil määral on see tõsi, kuid ainult võrreldes VB enda pakutava turvalise programmeerimisega. Kuid oskusliku kasutamise ja võimalike lõkse tundmise korral on see risk minimaalne. Lisaks on sageli lihtsalt võimatu Win API kasutamisest täielikult loobuda - neid läheb ikkagi vaja iga tõsise arenduse jaoks.

Lisaks mainisime varem laia DLL-klassi lõkse. Win API puhul on kõik palju lihtsam, kuna nendele funktsioonidele juurdepääsu vorm on selgelt ühtne. Tasub meeles pidada järgmisi põhipunkte:

1. Win32 API funktsioonid on just sellised: funktsioonid, see tähendab funktsiooni tüüpi protseduurid (Win16 API-s oli palju alamrutiine). Kõik need on pikka tüüpi funktsioonid, seega on nende kirjeldused kirjutatud järgmisel kujul: Deklareeri funktsiooni nimi ... As Long ‘funktsiooni tüüp _ on selgelt määratletud

   Declare Funktsiooni nimi& ‘ funktsiooni tüüp _ määratakse järelliide abil

   API-funktsiooni kutse näeb välja järgmine:

Tulemus& = ApiName& ([ Argumentide loend]

1. Kõige sagedamini on funktsiooni tagastusväärtus toimingu lõpukood. Pealegi tähendab nullist erinev väärtus sel juhul normaalset lõpetamist, null aga viga. Tavaliselt (kuid mitte alati) saate vea olemust selgitada funktsiooni GetLastError kutsumisega. Selle funktsiooni kirjeldus näeb välja selline: Deklareeri funktsioon GetLastError& Lib “kernel32” ()

   TÄHELEPANU! VB-s töötades on kvalifitseeritud veakoodi väärtuse saamiseks parem kasutada objekti Err atribuuti LastDLLError, kuna VB lähtestab mõnikord funktsiooni GetLastError API kutsumise ja programmi täitmise jätkamise vahel.

   Saate tõlgendada GelLastErrori tagastatud koodi, kasutades faili API32.TXT kirjutatud konstante, mille nimed algavad järelliitega ERROR_.

   Kõige tüüpilisematel vigadel on järgmised koodid:

   • ERROR_INVALID_HANDLE = 6& – vigane käepide
   • ERROR_CALL_NOT_IMPLEMENTED = 120& – funktsiooni kutsumine operatsioonisüsteemis Windows 9x, mis on saadaval ainult Windows NT jaoks
   • ERROR_INVALID_PARAMETER = 87& – vale parameetri väärtus

   Paljud funktsioonid tagastavad aga mõne nõutud parameetri väärtuse (näiteks OpenFile tagastab failikäepideme väärtuse). Sellistel juhtudel määrab vea mingi muu spetsiaalne Return& väärtus, enamasti 0 või –1.

2. Win32 API-d kasutavad kõige lihtsamate andmetüüpide edastamiseks rangelt fikseeritud viise. a) ByVal...As Long

   Vähemalt 80% argumentide edastamisest tehakse pikkade muutujate abil. Pange tähele, et argument Alati on kaasas ByVal märksõnaga ja see tähendab muuhulgas, et toimub ühesuunaline andmeedastus - VB programmist API funktsioonile.

   B) ByVal...As String

   Seda tüüpi andmeedastust esineb ka üsna sageli ja ka argumendiga Alati ByVal kehtib. API funktsiooni kutsumisel kirjutatakse virna stringi aadress, seega on sel juhul võimalik kahesuunaline andmevahetus. Nööridega töötamisel tuleb arvestada mitmete ohtudega.

   Esimene on see, et stringi jaoks tehakse mälureserveerimine kutsuvas programmis, nii et kui API funktsioon täidab stringe, peate enne selle väljakutsumist looma vajaliku suurusega stringi. Näiteks funktsioon GetWindowsDirectory tagastab tee Windowsi kataloogi, mis definitsiooni järgi ei tohi olla pikem kui 144 tähemärki. Sellest lähtuvalt peaks selle funktsiooni kutsumine välja nägema umbes selline:

   WinPath$ = Space$(144) ' reserveerib _ 144 tähemärgi pikkuse stringi Tulemus& = GetWindowsDirectory& (WinTath$, 144) _ ' puhvri täitmine ' Tulemus& - tegelik märkide arv kataloogi nimes _ WinPath$ = Vasak$(WinPath, Tulemus )

   Teine probleem seisneb selles, et API funktsiooni kutsumisel teisendatakse lähtestring mingiks sisemiseks esituseks ja funktsioonist väljumisel vastupidi. Kui Win16 päevil seisnes see operatsioon ainult nullbaidi lisamises rea lõppu, siis Win32 tulekuga lisandus see kahebaidise Unicode-kodeeringu teisendamisele ANSI-ks ja vastupidi. (Seda käsitleti üksikasjalikult artiklis “Stringi muutujatega töötamise omadused VB-s”, ComputerPress 10’99 ja 01’2000). Praegu pangem tähele, et kasutades ByVal ... String-konstruktsioonina saate stringe vahetada ainult märgiandmetega.

   B) ...nagu iganes

   See tähendab, et pinu lükatakse mingi mälupuhvri aadress, mille sisu tõlgendab näiteks API funktsioon olenevalt teiste argumentide väärtusest. As Any saab aga kasutada ainult Declare lauses – konkreetse funktsiooni kutsumisel tuleb argumendina defineerida konkreetne muutuja.

   D) ... Nagu UserDefinedType

   Seda kujundust kasutatakse sageli ka siis, kui on vaja andmeid vahetada (tavaliselt mõlemas suunas), kasutades mõnda struktuuri. Tegelikult on see konstruktsioon edastusvormi As Any konkreetne teostus, lihtsalt sel juhul on funktsioon konfigureeritud kindlale struktuurile.

   Andmestruktuuri vormi määrab konkreetne API funktsioon ning selle õige kirjeldamine ja reserveerimine kutsuvas programmis on programmeerija kohustus. See disain Alati kasutatud ilma sõnad ByVal, see tähendab, et sel juhul viiakse läbi viitepõhine ülekanne - muutuja aadress kirjutatakse pinu.

Näide API funktsiooni kutsumisest

Illustreerime ülaltoodud näidet kahe kasuliku funktsiooni kasutamise kohta failidega töötamiseks - lopen ja lread, mida kirjeldatakse järgmiselt:

Deklareerige funktsioon lopen Lib "kernel32" _ Alias ​​"_lopen" (_ ByVal lpFileName kui string, _ ByVal wReadWrite As Long) Deklareerige funktsioon lread Lib "kernel32" _ Alias ​​"_lread" (_ ByVal hFile As Long lppuhver nagu iga, _ ByVal wBytes As Long) nii kaua

VB-s on nende analoogid - antud juhul täpsed - operaatorid Open ja Get (binaarrežiimi jaoks). Pöörame kohe tähelepanu Alias-märksõna kasutamisele funktsioonide deklaratsioonis - see on täpselt nii, kui te ei saa ilma selleta hakkama. Tegelikud funktsiooninimed teegis algavad alakriipsuga (tüüpiline C-keele stiil), mis pole VB-s lubatud.

Faili avamise toiming võib välja näha järgmine:

Const INVALID_HANDLE_VALUE = -1 ' vale _ deskriptori väärtus lpFileName$ = "D:\calc.bas" ' faili nimi wReadWrite& = 2 ' lugemis-kirjutusrežiim hFile& = lopen(lpFailinimi$, wReadWrite&) _ ' defineerige faili kirjeldus või kui faili kirjeldus INVALID_HANDLE_VALUE Seejärel _ ' viga faili avamisel ' määrake veakood CodeError& = Err.LastDllError 'CodeError& = GetLastError _ ' see konstruktsioon ei tööta End If

Siin peate pöörama tähelepanu kahele punktile:

• funktsiooni väärtusena saame faili deskriptori väärtuse. Viga vastab väärtusele –1;
• Just sel juhul funktsiooni GetLastError kutsumine ei tööta - täpsustatud veaväärtuse saamiseks pöördusime objekti Err poole (sellise olukorra võimalusest rääkisime eespool).

Seejärel saab faili sisu lugeda, kuid see eeldab, et programmeerijal peab olema mingi arusaam selle struktuurist (nagu see juhtub suvaliste binaarfailidega töötamisel). Sel juhul võib funktsiooni lread kutsumine välja näha järgmine:

Dim MyVar As Single wBytes = lread (hFile&, MyVar, Len(MyVar) ' loeb reaalarvu, 4 baiti ' wBytes on tegelikult loetud andmete arv, ' -1 on viga... Sisestage MyStruct x As Single i As Täisarvu lõpu tüüp Dim MyVar As MyStruct wBytes = lread (hFile&, MyVar, Len(MyVar)) ' loetud andmestruktuur, 6 baiti

Pange tähele veelkord: funktsiooni teine ​​argument edastatakse viitega, ülejäänud edastatakse väärtuse järgi.

Dim MyVar As String MyVar = Space$(10) ‘reserveeri muutuja 10 märgi jaoks wBytes = lread (hFile&, ByVal MyVar, Len(MyVar)) ‘ loe märgistringi, 10 tähemärki

Siin on näha oluline erinevus eelmisest näitest – stringi muutujaga kaasneb tingimata ByVal märksõna.

Massiivis oleva faili sisu lugemine (lihtsuse huvides kasutame ühemõõtmelist baidimassiivi) toimub järgmiselt:

Dim MyArray(1 kuni 10) Baitena wBytes = lread (hFile&, MyArray(1), _ Len(MyArray(1))* 10) ‘ loe 10 massiivi elementi

Määrates argumendiks massiivi esimese elemendi, edastame massiivi jaoks reserveeritud mäluala alguse aadressi. Ilmselgelt saate massiivi mis tahes fragmendi täita järgmiselt:

WBytes = lread (hFile&, MyArray(4), _ Len(MyArray(1))* 5) ‘ loe massiivi elemente 4 kuni 8

5. nõuanne: kasutage Gearsi jaoks aliast ja parameetrid Nagu mis tahes

Siin avaldame eelmise näite põhjal Dan Applemani neljanda näpunäite olemuse.

Funktsiooniga lread töötades tuleks meeles pidada, et stringimuutuja abil sellele juurde pääsedes tuleb kasutada märksõna ByVal (muidu saate teateid illegaalse toimingu kohta). Enda kaitsmiseks saate teha sama funktsiooni täiendava erikirjelduse, mis töötab ainult stringimuutujatega:

Deklareeri funktsioon lreadString Lib "kernel32" _ alias "_lread" (_ ByVal hFile As Long, ByVal lpBuffer kui string, _ ByVal wBytes As Long) nii pikk

Selle kirjeldusega töötades ei pea te enam määrama ByVal'i, kui võtate ühendust:

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

Näib, et operaatori Declare süntaks võimaldab teil teha massiivi jaoks sarnase erikirjelduse:

Deklareerige funktsioon lreadString Lib "kernel32" alias "_lread" (_ ByVal hFile As Long, lpBuffer() kui bait, _ ByVal wBytes As Long) kui pikk

Siiski pöördumine

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

paratamatult toob kaasa fataalse programmivea.

See on jätk vestlusele Visual Basicu stringimuutujate töötlemise iseärasustest: VB kasutab kahebaidist Unicode'i kodeeringut, Win API ühebaidist ANSI-d (ja C-vormingus - nullbaidiga lõpus) . Sellest lähtuvalt toimub stringimuutujate argumendina kasutamisel alati API funktsiooni (täpsemalt DLL funktsiooni) kutsumisel automaatselt Unicode'i konverteerimine ANSI-le ja naasmisel pöördkonversioon.

Siit on lihtne väljavõte: stringi muutujaid saab kasutada märgiandmete vahetamiseks, kuid neid ei saa kasutada suvalise binaarse teabe vahetamiseks (nagu VB 16-bitiste versioonide puhul). Viimasel juhul on parem kasutada ühemõõtmelist baidimassiivi.

Nagu teate, saab stringi tüüpi kasutada kohandatud struktuuri kirjeldamiseks. Sellega seoses peate meeles pidama järgmist:

• Rangelt keelatud on kasutada Win API-le juurdepääsuks järgmist konstruktsiooni: Tippige MyStruct x As Single s As String ‘muutuva pikkusega stringi lõpu tüüp

  Muutuva pikkusega stringi puhul edastatakse struktuuri osana stringi deskriptor koos kõigi sellest tulenevate tagajärgedega programmi täitmisvea näol.

• Struktuurielemendina saate kasutada fikseeritud pikkusega stringi: Tippige MyStruct x As Single s As String*8 ‘ fikseeritud pikkusega stringi lõpu tüüp

Sel juhul tehakse vastav kodeeringu teisendus.

Ja viimane märkus: mingil juhul ei tohi API-funktsioonile juurde pääsedes kasutada stringimuutujate massiivi (nii fikseeritud kui ka muutuva pikkusega). Vastasel juhul on "ebaseadusliku operatsiooni" tekkimine tagatud.

Tõenäoliselt tekib olukord, kus peate ise kirjutama DLL-i funktsioonid. Vajadus selle järele tekib paratamatult, kui kasutate segaprogrammeerimistehnoloogiat - ühe rakenduse rakendamiseks kahte või enamat programmeerimiskeelt.

Sellega seoses märgime, et segaprogrammeerimine on üsna keeruka rakenduse rakendamiseks üsna tavaline. Tõepoolest, igal keelel (täpsemalt keelel põhineval programmeerimissüsteemil) on oma tugevad ja nõrgad küljed, mistõttu on üsna loogiline kasutada erinevate probleemide lahendamiseks erinevaid tööriistu. Näiteks VB - kasutajaliidese loomiseks, C - süsteemiressurssidele tõhusaks juurdepääsuks, Fortran - numbriliste algoritmide rakendamiseks.

Autori arvamus on järgmine: iga tõsine programmeerimine eeldab, et arendaja peab valdama vähemalt kahte tööriista. Muidugi on tänapäevastes selge tööjaotuse tingimustes väga raske olla suurepärane ekspert isegi kahes süsteemis, seega on skeem “põhi- ja abikeeled” loogilisem. Mõte seisneb siin selles, et isegi “abikeele” pealiskaudne tundmine (üsna lihtsate protseduuride kirjutamine) võib “peamise” kasutamise efektiivsust oluliselt parandada. Pange tähele, et VB tundmine, vähemalt abistamiseks, on tänapäeval professionaalsele programmeerijale peaaegu kohustuslik nõue. Muide, DOS-i päevil olid Assembleri põhitõdede tundmine iga programmeerija jaoks äärmiselt ihaldusväärne, sealhulgas Basicu jaoks.

Ühel või teisel viisil, isegi rühmatöös, kui iga programmeerija tegeleb oma konkreetse ülesandega, peaks kõigil projektis osalejatel olema ettekujutus protseduurilise liidese funktsioonidest erinevates keeltes. Ja teadke, et paljud programmeerimissüsteemid (sealhulgas VB) võimaldavad lisaks vaikeliidesele kasutada ka muid täiustatud meetodeid juurdepääsuks protseduuridele, mis võimaldavad liidest mõne teise keelega kohandada.

Protseduuridevahelise liidese uurimisel peaksite pöörama tähelepanu järgmistele võimalikele lõksudele:

• Erinevad keeled võivad identifikaatorite kirjutamisel kasutada erinevaid tavasid. Näiteks on tavaline, et protseduuri nime alguses kasutatakse alljoont, mis pole VB-s lubatud. See probleem on hõlpsasti lahendatav, kui kasutate Declare'i avalduses märksõna Alias ​​(vt näidisnõuannet 2.3).
• Saab kasutada teistsugust virnale edastatud argumentide kirjutamise jada. Näiteks DOS-i päevil (ma tunnistan ausalt, ma ei tea, kuidas see praegu Windowsi keskkonnas välja näeb) kirjutas C argumendid loendi lõpust, teised keeled (Fortran, Pascal, Basic) - algusest peale.
• Vaikimisi kasutatakse erinevaid parameetrite edastamise põhimõtteid – viite või väärtuse järgi.
• Stringimuutujate salvestamise erinevad põhimõtted. Näiteks C-s (nagu ka Fortranis ja Pascalis) määrab stringi pikkuse selle lõpus olev nullbait, kuid Basicu puhul kirjutatakse pikkus eksplitsiitselt stringi deskriptorisse. Muidugi tuleb silmas pidada võimalust kasutada erinevaid märgikodeeringuid.
• Mitmemõõtmeliste massiivide ülekandmisel peaksite meeles pidama, et mitmemõõtmeliste struktuuride ühemõõtmelisteks teisendamiseks on võimalikud mitmesugused võimalused (alustades esimesest indeksist või viimasest, kahemõõtmeliste massiivide suhtes - "ridade" või "veergude järgi" ).

Seda kõike arvesse võttes saab sõnastada järgmised soovitused:

• Kasutage DLL-i funktsioonidele argumentide edastamiseks lihtsamaid ja tõestatud meetodeid. Win API jaoks vastu võetud standardid on mudeliks üsna sobivad.
• Ärge kunagi edastage stringimuutujate massiive.
• Olge lihtsate stringimuutujate ja mitmemõõtmeliste massiivide edastamisel väga ettevaatlik.
• Kontrollige kindlasti spetsiaalselt mehhanismi funktsionaalsust argumentide edastamiseks kutsutud protseduurile ja tagasi. Kirjutage andmeedastuse kontrollimiseks spetsiaalne test. Kontrollige eraldi, kas iga argument on õigesti edastatud. Näiteks kui teil on mitme argumendiga protseduur, kontrollige esmalt, et iga parameeter on õigesti edastatud ühe argumendi suvandi jaoks ja alles seejärel kogu loendi jaoks.

Aga mis siis, kui DLL-i funktsioon on näiteks Fortranis juba kirjutatud, kuid selle sisendliides ei sobi eriti hästi ülaltoodud VB standarditega? Siin on kaks nõuannet. Esiteks: kirjutage DLL-i testfunktsioon ja kasutage seda, et leida VB-programmist katse-eksituse meetodil soovitud kõne. Teiseks: kirjutage samasse Fortranis adapterprotseduur, mis annaks lihtsa liidese VB ja DLL-funktsiooni vahel, muutes lihtsad andmestruktuurid keerukateks (näiteks teisendage mitmemõõtmeline baidimassiivi stringimassiiviks).

Niisiis: kasutage DLL-i funktsioone. Aga olge valvsad...

ComputerPress 9"2000

Wikipedia definitsiooni järgi on API valmis klasside, protseduuride, funktsioonide, struktuuride ja konstantide kogum, mille pakub rakendus (teegi, teenus) kasutamiseks välistes tarkvaratoodetes. Programmeerijad kasutavad seda igasuguste rakenduste kirjutamiseks.

Kuid kuna suur osa Wikipediast pole paljudele arusaadav, püüan võhiku terminitega selgitada, mis on API ja milleks need tavaliselt tehakse ja kuidas neid kasutatakse.

API-d on täiesti erinevad, kuid näitena valisin olukorra, kus meil on kaupluste võrk ja ainult üks ühine andmebaas. Kujutage ette, et teil on sidusprogramm. Sidusprogramm töötab järgmisel põhimõttel: inimene registreerub sidusprogrammi ja saab poemootori. Seejärel saab ta selle poe oma hostimisse installida ja tööle hakata. Kuid kõik selle poe andmed on võetud meie andmebaasist, see tähendab, et me peame andma igale partnerile juurdepääsu meie väärtuslikule andmebaasile. Kas kujutate ette, kui ohtlik see on? Peame ju avama juurdepääsu andmebaasile väljastpoolt, et kõik partnerpoed saaksid sellega töötada. Mis juhtub, kui teie juurdepääsuandmed satuvad kurjategijate kätte?

Siin aitab meid API. Selle asemel, et anda juurdepääs andmebaasile, teeme lihtsalt API, mille kaudu partnerkauplused saavad teavet. Nii töötab andmebaasiga ainult meie API skript ja selle skriptiga töötavad kauplused.

Kuidas see töötab?
Näiteks saadab pood meie API-le päringu
http://ourapi.com/get_books?limit=20
ja meie API mõistab, et ta peab esitama raamatute loendi, mis koosneb 20 eksemplarist, kuna me edastasime piirangu parameetri, mis on võrdne 20-ga. Meie skript (API) esitab päringu andmebaasile, võtab vastu raamatute loendi ja tagastab need salvestada (tegelikult lihtsalt kuvab ) kindlas vormingus. Vorming, milles API infot tagastab, võib olla absoluutselt ükskõik milline, peaasi, et meie poed sellest aru saaksid. See võib olla JSON, serialiseeritud massiiv või XML. See pole enam oluline, peaasi, et sa põhimõttest aru saad.

Saate ise määrata käskude komplekti, millest API aru saab. Näiteks meie puhul võivad need olla sellised käsud nagu raamatute loendi hankimine, kategooriate loendi hankimine, populaarsete raamatute hankimine, uute raamatute hankimine jne. Nii et isegi kui ründajal avaneb võimalus pääseda juurde meie API-le, ei saa ta teha muud, kui hankida raamatute loend ja see ei ohusta meie andmebaasi.

Loodan, et suutsin lihtsa näitega selgitada, mis on API. Kui teil on küsimusi, küsige neid kommentaarides või foorumis ja aitame teid hea meelega nende lahendamisel.

See lühiajaline tähtaeg on hästi teada kõigile, kellel on arendusega vähegi kogemusi. Kuid mitte kõik ei mõista, mida see täpselt tähendab ja miks seda vaja on. Arendaja Peeter Gazarov rääkis API-st oma ajaveebis lihtsate sõnadega.

Lühend API tähistab "Application Programming Interface" (rakenduse programmeerimisliides, rakenduste programmeerimisliides). Enamik suuri ettevõtteid arendab mingil etapil API-sid klientidele või sisekasutuseks. Et mõista, kuidas ja kuidas API-sid arenduses ja äritegevuses kasutatakse, peate esmalt mõistma, kuidas World Wide Web töötab.

World Wide Web ja kaugserverid

WWW-d võib pidada tohutuks omavahel ühendatud serverite võrguks, kuhu salvestatakse iga leht. Tavalisest sülearvutist saab teha serveri, mis suudab teenindada võrgus tervet veebisaiti, ja arendajad kasutavad veebisaitide loomiseks kohalikke servereid enne nende avamist paljudele kasutajatele.

Kui sisestatakse brauseri aadressiribale www.facebook.com Facebooki kaugserverisse saadetakse vastav päring. Kui brauser saab vastuse, tõlgendab see koodi ja kuvab lehe.

Iga kord, kui kasutaja külastab mõnda Interneti-lehekülge, suhtleb ta kaugserveri API-ga. API on serveri komponent, mis võtab vastu päringuid ja saadab vastuseid.

API kui viis klientide teenindamiseks

Paljud ettevõtted pakuvad API-sid valmistootena. Näiteks Weather Underground müüb juurdepääsu oma ilmaandmete API-le.

Kasutusstsenaarium: Väikeettevõtte kodulehel on vorm klientidele aegade kokkuleppimiseks. Ettevõte soovib sellesse integreerida Google'i kalendri, et anda klientidele võimalus automaatselt sündmus luua ja eelseisva koosoleku üksikasju sisestada.

API rakendus: Eesmärk on, et saidiserver võtaks otse ühendust Google'i serveriga, paludes luua määratud üksikasjadega sündmus, saada Google'i vastus, seda töödelda ja saadab brauserisse vastava teabe, näiteks kasutajale kinnitussõnumi. .

Teise võimalusena saab brauser teha päringu Google'i serveri API-le ilma ettevõtte serverit läbimata.

Mille poolest erineb Google Calendar API mis tahes muu võrgus oleva kaugserveri API-st?

Tehniliselt on erinevus päringu ja vastuse vormingus. Täieliku veebilehe loomiseks ootab brauser vastust HTML-i märgistuskeeles, samas kui Google Calendar API tagastab andmed lihtsalt JSON-vormingus.

Kui API-le päringu teeb ettevõtte veebisaidi server, siis on see klient (nagu brauser on klient veebilehe avamisel).

Tänu API-le saab kasutaja võimaluse sooritada toiming ettevõtte veebisaidilt lahkumata.

Enamik kaasaegseid veebisaite kasutab vähemalt mõnda kolmanda osapoole API-d. Paljudel ülesannetel on juba valmislahendused, mida pakuvad kolmanda osapoole arendajad, olgu selleks siis raamatukogu või teenus. Sageli on lihtsam ja usaldusväärsem kasutada valmislahendust.

Paljud arendajad levitavad rakendust mitmele serverile, mis suhtlevad üksteisega API abil. Servereid, mis täidavad peamist rakendusserverit toetavat funktsiooni, nimetatakse mikroteenusteks.

Seega, kui ettevõte pakub oma kasutajatele API-d, tähendab see lihtsalt seda, et ta on loonud rea spetsiaalseid URL-e, mis tagastavad vastusena ainult andmed.

Selliseid taotlusi saab sageli saata brauseri kaudu. Kuna HTTP andmeedastus toimub teksti kujul, saab brauser alati vastust kuvada. Näiteks pääsete brauseri kaudu otse GitHubi API-le (https://api.github.com/users/petrgazarov), ilma juurdepääsuloata, ja saate selle vastuse JSON-vormingus:

Brauser kuvab suurepäraselt JSON-i vastuse, mille saab koodi sisestada. Sellisest tekstist on piisavalt lihtne andmeid eraldada, et neid oma äranägemise järgi kasutada.

Veel mõned API näited

Sõnal "rakendus" võib olla erinev tähendus. API kontekstis tähendab see järgmist:

• kindla funktsiooniga tarkvara,
• kogu server, kogu rakendus või lihtsalt rakenduse eraldi osa.

Iga tarkvara, mida saab keskkonnast selgelt eristada, võib asendada ingliskeelses lühendis tähte “A” ja sellel võib olla ka mingi API. Näiteks kui arendaja rakendab koodi kolmanda osapoole teegi, saab sellest kogu rakenduse osa. Eraldiseisva tarkvarana on raamatukogul mingi API, mis võimaldab tal suhelda ülejäänud rakenduse koodiga.

Objektorienteeritud disainis kujutatakse koodi objektide kogumina. Rakenduses võib selliseid objekte üksteisega suhelda sadu. Igal neist on oma API - komplekt avalik omadused ja meetodid teiste rakenduse objektidega suhtlemiseks. Objektidel võib olla ka privaatne, sisemine loogika, mis on keskkonna eest peidetud ega ole API.