Sandbox

çelik, vizon, viçi, letër 26 nëntor 2012 në 13:59

Çfarë është API

pershendetje!
Në këtë artikull, ne do të shohim se çfarë është një API, ku, si dhe për çfarë përdoret. Ne do të shikojmë gjithashtu se si API mund të aplikohet në zhvillimin tuaj të internetit dhe se si mund të thjeshtojë jetën e një programuesi në internet.

Pra, le të fillojmë me përkufizimin. API (Application Programming Interface) është një ndërfaqe programimi, një ndërfaqe për krijimin e aplikacioneve. Në një gjuhë më të kuptueshme, API është një kod i gatshëm për të thjeshtuar jetën e një programuesi. API u krijua në mënyrë që një programues të mund të lehtësonte me të vërtetë detyrën e shkrimit të një aplikacioni duke përdorur kodin e gatshëm (për shembull, funksionet). jQuery i njohur i shkruar në JavaScript është gjithashtu një lloj API. Nëse marrim parasysh këtë shembull të veçantë, atëherë jQuery e bën shumë më të lehtë shkrimin e kodit. Ajo që mund të bëhet në 30 rreshta me mjete të zakonshme JavaScript shkruhet përmes jQuery në 5-6. Nëse shikojmë API-në në përgjithësi, atëherë mund të gjeni shumë shërbime që përfaqësojnë zgjidhje për zhvillim. Më i famshmi sot është shërbimi code.google.com, i cili ofron rreth pesëdhjetë API të ndryshme! Kjo është një ndërfaqe për krijimin e aplikacioneve Android, dhe API të ndryshme për të punuar me AJAX, dhe API të ndryshme aplikacionesh që mund t'i personalizoni lehtësisht sipas dëshirës tuaj.

Në fund të fundit, a ka kuptim të shkruani kodin me duart tuaja? Pse të punohet në atë që është krijuar tashmë? A ka kuptim të heqësh dorë nga zgjidhjet falas (dhe në fakt, ndihma falas) në zhvillimin e uebit? Nëse i jeni përgjigjur "JO" të gjitha këtyre pyetjeve, atëherë supozoni se e kuptoni thelbin e API-së.

Por dua të bëj edhe një rezervim. Zhvilluesit fillestar NUK duhet të përdorin zgjidhje gjysmë të gatshme, pasi ata nuk do të përballen me detyrën reale në të ardhmen. Prandaj, nëse jeni një programues fillestar në internet, atëherë mos përdorni produkte gjysëm të gatshme! Mësoni të mendoni me kokën tuaj, ndërtoni algoritme të ndryshme për të kuptuar thelbin e programimit. E them gjithashtu, duke iu drejtuar tashmë të gjithëve, se API nuk është zgjidhje e gatshme, është një mjedis, një ndërfaqe për krijimin e projekteve tuaja. Ju nuk hani burgers të ngrirë nga dyqani, apo jo? Ju i skuqni fillimisht, apo jo? Kjo analogji është shumë e qartë për thelbin e API.

Në përgjithësi, ju thashë se çfarë është një API, ku dhe si përdoret, gjëja më e rëndësishme për çfarë. Ju uroj një studim të këndshëm të programimit të uebit dhe të kuptuarit e thellësive gjithnjë e më të mëdha të tij!

Etiketa: api

Ky artikull nuk është subjekt komentimi, pasi autori i tij nuk është ende një anëtar i plotë i komunitetit. Ju do të mund të kontaktoni autorin vetëm pasi ai të marrë

Windows API - një grup funksionesh të sistemit operativ

Shkurtesa API duket për shumë programues fillestarë të jetë shumë misterioze dhe madje frikësuese. Në fakt, ndërfaqja e programimit të aplikacionit (API) është vetëm një grup i gatshëm funksionesh që zhvilluesit e aplikacioneve mund të përdorin. Në përgjithësi, ky koncept është ekuivalent me atë që dikur quhej një bibliotekë rutinash. Sidoqoftë, API zakonisht i referohet një kategorie të veçantë të bibliotekave të tilla.

Gjatë zhvillimit të pothuajse çdo aplikacioni mjaft kompleks (MyAppation) për përdoruesin fundor, formohet një grup funksionesh specifike të brendshme të përdorura për zbatimin e këtij programi të veçantë, i cili quhet MyApplication API. Sidoqoftë, shpesh rezulton se këto funksione mund të përdoren në mënyrë efektive për të krijuar aplikacione të tjera, duke përfshirë programues të tjerë. Në këtë rast, autorët, bazuar në strategjinë e promovimit të produktit të tyre, duhet të vendosin pyetjen: a e hapin aksesin në këtë grup për përdoruesit e jashtëm apo jo? Nëse përgjigja është po në përshkrimin e paketës së softuerit, fraza shfaqet si një karakteristikë pozitive: "Kit përfshin një grup të hapur funksionesh API" (por ndonjëherë për para shtesë).

Kështu, më shpesh, një API nënkupton një grup funksionesh që janë pjesë e një aplikacioni, por në të njëjtën kohë janë të disponueshme për përdorim në programe të tjera. Për shembull, Excel, përveç një ndërfaqe për përdoruesin fundor, ka një grup funksionesh Excel API që mund të përdoren, në veçanti, kur krijohen aplikacione duke përdorur VB.

Prandaj, Windows API është një grup funksionesh që është pjesë e vetë sistemit operativ dhe në të njëjtën kohë është i disponueshëm për çdo aplikacion tjetër, përfshirë ato të shkruara duke përdorur VB. Në këtë drejtim, analogjia me grupin e ndërprerjeve të sistemit BIOS / DOS, i cili në fakt është një API DOS, është mjaft i justifikuar.

Dallimi qëndron në faktin se përbërja e funksioneve të Windows API, nga njëra anë, është shumë më e gjerë se në DOS, nga ana tjetër, nuk përfshin shumë nga mjetet për kontrollin e drejtpërdrejtë të burimeve kompjuterike që ishin në dispozicion të programuesit në sistemin operativ të mëparshëm. Për më tepër, API-ja e Windows aksesohet duke përdorur thirrje të rregullta procedurale dhe thirrjet e funksionit DOS bëhen përmes një komande të veçantë të makinës së procesorit të quajtur Interrupt.

Pse keni nevojë për Win API për programuesit VB

Përkundër faktit se VB ka një larmi të madhe funksionesh, në procesin e zhvillimit pak a shumë serioz, rezulton se aftësitë e tyre shpesh nuk janë të mjaftueshme për të zgjidhur detyrat e nevojshme. Në të njëjtën kohë, programuesit fillestarë shpesh fillojnë të ankohen për mangësitë e VB dhe mendojnë për ndryshimin e mjetit, duke mos dyshuar se ka një grup të madh mjetesh në kompjuterin e tyre dhe thjesht duhet të jeni në gjendje t'i përdorni ato.

Pas njohjes me Win API, zbulohet se shumë funksione të integruara të VB nuk janë asgjë më shumë se thirrje për procedurat përkatëse të sistemit, por zbatohen vetëm në formën e sintaksës së kësaj gjuhe. Duke pasur parasysh këtë, nevoja për të përdorur API përcaktohet nga opsionet e mëposhtme:

1. Funksionet API që janë implementuar plotësisht si funksione të integruara VB. Sidoqoftë, ndonjëherë, në këtë rast, është gjithashtu e dobishme të kaloni në përdorimin e API, pasi kjo ndonjëherë mund të rrisë ndjeshëm performancën (në veçanti, për shkak të mungesës së transformimeve të panevojshme të parametrave të kaluar).
2. Funksionet e integruara VB zbatojnë vetëm një rast të veçantë të funksionit përkatës API. Ky është një opsion mjaft i zakonshëm. Për shembull, CreateDirectory API është më i fuqishëm se operatori i integruar VB MkDir.
3. Një numër i madh i funksioneve API nuk kanë fare analoge në versionin aktual të gjuhës VB. Për shembull, nuk mund të fshini një drejtori duke përdorur VB - duhet të përdorni funksionin DeleteDirectory për ta bërë këtë.

Duhet gjithashtu të theksohet se disa funksione API (pjesa e tyre në API Win është shumë e vogël) nuk mund të thirren nga programet VB për shkak të një numri kufizimesh gjuhësore, për shembull, për shkak të mungesës së aftësisë për të punuar me adresat e kujtesës. Por në disa raste, teknikat e programimit jo të parëndësishëm mund të ndihmojnë (në veçanti, në rastin e të njëjtave adresa).

Pikëpamja personale e autorit është se në vend që të zgjerohet nga versioni në version i funksioneve të integruara VB, duhet të jepet një përshkrim i mirë i funksioneve më të zakonshme API. Në të njëjtën kohë, unë do të doja të këshilloja zhvilluesit që të mos presin për një version të ri të mjetit me funksione të avancuara, por të studiojnë më nga afër API-në ekzistuese Win - ka të ngjarë që aftësitë që ju nevojiten të mund të ishin zbatuar tashmë në Versioni VB 1.0 i lëshimit të vitit 1991.

Si të mësoni Win API

Kjo nuk është një pyetje aq e lehtë, duke marrë parasysh se numri i funksioneve të Win32 API vlerësohet në rreth 10 mijë (askush nuk e di shifrën e saktë, madje as Microsoft).

VB (versionet 4-6) përfshin një skedar me përshkrimin e deklaratave të Win API - WIN32API.TXT (ne do t'ju tregojmë më shumë rreth përdorimit të tij më vonë). Por, së pari, ai mund të përdoret për të marrë informacion në lidhje me qëllimin e një funksioni të veçantë dhe parametrat e tij vetëm nga emrat kujtues të përdorur, dhe së dyti, lista e funksioneve në këtë skedar nuk është aspak e plotë. Në një kohë (shtatë vjet më parë) në VB 3.0 kishte skedarë të posaçëm ndihmës që përshkruanin funksionet e Win16 API. Megjithatë, tashmë në v.4.0 ky informacion i dobishëm me një ndërfaqe miqësore për përdoruesit u zhduk.

Informacione gjithëpërfshirëse rreth Win32 API mund të gjenden në Ndihmën e Kit për Zhvillimin e Softuerit të Platformës, e cila gjendet veçanërisht në CD-të e Bibliotekës MSDN të përfshira me VB 5.0 dhe 6.0 Enterprise Edition dhe Office 2000 Developer Edition. Megjithatë, nuk është aspak e lehtë të gjesh aty informacionin e nevojshëm dhe ta kuptosh. Për të mos përmendur faktin që të gjitha përshkrimet atje janë dhënë në lidhje me gjuhën C.

Librat e ekspertit të njohur amerikan Daniel Appleman njihen përgjithësisht në botë si një udhëzues për të mësuar programimin API në mjedisin VB. Seria e tij Dan Appleman's Visual Basic Programmer's Guide to Windows API (për Win16, Win32, aplikuar në versione të ndryshme të VB) ka qenë vazhdimisht një nga më të shiturit për programuesit VB që nga viti 1993. Udhëzuesi i programuesit VB 5.0 të Dan Appleman për API-në Win32, botuar në 1997, iu soll autorit nga Shtetet e Bashkuara nga një mik që e gjeti në librarinë e parë në një qytet të vogël provincial.

Ky libër, mbi 1500 faqe, përfshin një metodologji të përgjithshme për programimin API në mjedisin VB, si dhe mbi 900 funksione. CD-ROM-i shoqërues përmban tekstin e plotë të librit dhe të gjithë shembujt e programit, si dhe disa kapituj shtesë që nuk janë përfshirë në versionin e printuar. Në vitin 1999, Dan Appleman lëshoi ​​librin dhe udhëzuesin për programuesit Visual Basic të Dan Appleman's Win32 API, i cili përfshin informacione për 7600 funksione të tjera (megjithëse më pak të plota).

Win API dhe Biblioteka e Lidhjeve Dinamike (DLL)

Seti Win API zbatohet si DLL dinamike. Më tej, ne në fakt do të flasim për teknologjinë e përdorimit të DLL-ve në mjedisin VB duke përdorur shembullin e bibliotekave që janë pjesë e Win API. Megjithatë, ka disa pika të rëndësishme për t'u theksuar kur flasim për DLL.

Në këtë rast, me DLL, nënkuptojmë versionin tradicional të bibliotekave dinamike binare që ofrojnë thirrje të drejtpërdrejta të aplikimit për procedurat e kërkuara - nënrutina ose funksione (në të njëjtën mënyrë siç ndodh kur thirren procedura brenda një projekti VB). Biblioteka të tilla mund të krijohen duke përdorur mjete të ndryshme: VC ++, Delphi, Fortran, përveç VB (le të shohim se çfarë shfaqet në versionin 7.0) - kjo e fundit mund të bëjë vetëm DLL ActiveX, të cilat arrihen përmes ndërfaqes OLE Automation.

Zakonisht, skedarët DLL kanë shtesën .DLL, por kjo nuk është e nevojshme (për Win16, ekstensioni .EXE përdorej shpesh); drejtuesit e pajisjeve të jashtme identifikohen me .DRV.

Siç kemi vërejtur, është e vështirë të përcaktohet numri i saktë i funksioneve të Windows API dhe skedarët që i përmbajnë ato, por të gjitha ato ndodhen në drejtorinë e sistemit. Në këtë drejtim, është më mirë të theksohet përbërja e bibliotekave të përfshira në kernelin e sistemit operativ, dhe bibliotekat kryesore me funksione kryesore shtesë.

Tani për disa këshilla.

Këshillë 1. Sigurohuni që reklama juaj DL të jetë formatuar saktë L-procedurat

Thirrja aktuale për procedurat DLL në program duket saktësisht e njëjtë me procedurat "e zakonshme" të Visual Basic, për shembull:

Thirrni DllName ([lista e argumenteve])

Sidoqoftë, për të përdorur funksione të jashtme DLL (përfshirë Win API), ato duhet të deklarohen në program duke përdorur deklaratën Declare, e cila duket si kjo:

Deklaroni Nën-ProcedurënName Lib _ “LibraryName” _ [([ArgumentList])]

Deklaroni funksionin FunctionName _ Lib “LibraryName” _ [([ArgumentList])]

Këtu, në kllapa katrore, jepen elementet opsionale të operatorit, shprehjet e ndryshueshme janë me shkronja të pjerrëta, pjesa tjetër e fjalëve janë fjalë kyçe. Sistemi i ndihmës ofron një përshkrim mjaft të mirë të sintaksës së operatorit, kështu që tani për tani do të shënojmë vetëm disa pika.

Deklaratat e funksioneve të jashtme duhet të vendosen në seksionin Deklaratat e Përgjithshme të modulit. Nëse e vendosni në një modul formulari, atëherë duhet të specifikoni fjalën kyçe Private (kjo deklaratë do të jetë e disponueshme vetëm brenda këtij moduli) - ky është një kufizim për të gjitha procedurat e modulit të formularit.

Kompleti Win32 API zbatohet vetëm si funksione (ka pasur shumë Subs në Win16 API). Shumica e tyre janë funksione të tipit Long, të cilat më së shpeshti kthejnë një kod përfundimi operacioni.

Deklarata e Deklaratës u shfaq në MS Basic në ditët e DOS-it dhe përdorej gjithashtu për të deklaruar procedurat e brendshme të një projekti. Në Visual Basic, kjo nuk kërkohet sepse deklarimi i procedurave të brendshme është automatikisht përshkrimi i nën ose funksioni i tyre. Krahasuar me Basic / DOS, në përshkrimin e ri është e detyrueshme të tregohet emri i skedarit të bibliotekës ku ndodhet procedura e kërkuar. Bibliotekat Wip API ndodhen në drejtorinë e sistemit Windows, kështu që mjafton vetëm emri i skedarit. Nëse i referoheni një DLL të vendosur në një vendndodhje arbitrare, duhet të shkruani shtegun e plotë për këtë skedar.

Përshkrimi i deklaratës së deklaratës zakonisht merr shumë hapësirë ​​dhe nuk përshtatet në një rresht në dritaren e kodit. Prandaj, ju rekomandojmë që t'i përmbaheni një skeme specifike të mbështjelljes së linjës kur shkruani aplikacione, për shembull:

Deklaroni Funksionin GetTempPath _ Lib "kernel32" Alias ​​"GetTempPathA" _ (ByVal nBufferLength As Long, _ ByVal lpBuffer As String) Për aq kohë sa

Në këtë rast, të gjithë elementët kryesorë të përshkrimit janë të ndarë në rreshta të ndryshëm dhe për këtë arsye janë të lehta për t'u lexuar.

Këshillë 2. Jini veçanërisht të kujdesshëm kur punoni me funksionet DLL

Përdorimi i Win API dhe funksione të ndryshme DLL zgjeron ndjeshëm funksionalitetin e VB dhe shpesh përmirëson performancën e programeve. Megjithatë, ndëshkimi për këtë është rreziku i reduktimit të besueshmërisë së aplikacionit, veçanërisht gjatë korrigjimit.

Një nga avantazhet më të rëndësishme të mjedisit VB është besueshmëria e procesit të zhvillimit të programit: duke funksionuar nën kontrollin e interpretuesit, kodi i programit teorikisht nuk mund të prishë punën e Windows dhe vetë VB. Programuesi mund të mos jetë shumë i kujdesshëm në lidhje me korrektësinë e kalimit të parametrave në funksionet e thirrura - gabime të tilla do të zbulohen lehtësisht nga vetë interpretuesi, qoftë gjatë përkthimit të kodit, qoftë gjatë ekzekutimit të tij. Në rastin më të pakëndshëm, mënyra e përpunimit thjesht do të ndërpritet, me një tregues se ku dhe pse ndodhi gabimi.

Përdorimi i API-ve të Windows ose DLL-ve të tjera heq drejtpërdrejt këtë kontroll mbi transferimin e të dhënave dhe ekzekutimin e kodit jashtë mjedisit VB. Prandaj, një gabim në thirrjen për funksionet e jashtme mund të çojë në mosfunksionim si të VB ashtu edhe të sistemit operativ. Kjo është veçanërisht e vërtetë në fazën e zhvillimit të programit, kur prania e gabimeve është mjaft e natyrshme. Kështu, duke përdorur aftësitë më të gjera të funksioneve të shtresës bazë të sistemit, programuesi merr përgjegjësinë për përdorimin e duhur të tyre.

Problemi përkeqësohet nga fakti se gjuhë të ndryshme programimi përdorin mënyra të ndryshme për të kaluar parametra midis procedurave. (Më saktë, metoda të ndryshme transferimi përdoren si parazgjedhje, pasi shumë gjuhë mund të mbështesin metoda të shumta.) API-të Win zbatohen në C / C ++ dhe përdorin konventat e kalimit të parametrave të atij sistemi, të cilat ndryshojnë nga VB e zakonshme version.

Në këtë drejtim, duhet të theksohet se shfaqja e analogëve të funksioneve API të integruara në VB justifikohet pikërisht nga përshtatja e kësaj të fundit në sintaksën VB dhe zbatimi i mekanizmit përkatës të kontrollit të shkëmbimit të të dhënave. Vini re gjithashtu se në fazën e korrigjimit eksperimental të aplikacionit, kur krijoni një modul të ekzekutueshëm, është më mirë të përdorni opsionin e përpilimit të kodit P në vend të Kodit Native (kodi i makinerisë). Në rastin e parë, programi do të funksionojë nën kontrollin e përkthyesit - më i ngadalshëm në krahasim me kodin e makinës, por më i besueshëm nga pikëpamja e ndikimit të mundshëm të gabuar në sistemin operativ dhe duke siguruar një mënyrë më të përshtatshme për identifikimin e gabimeve të mundshme.

Këshillë 3: Dhjetë praktikat më të mira të Dan Appleman për programim të fortë API në VB

Përdorimi i një funksioni API kërkon programim më të kujdesshëm duke përdorur disa metoda jo shumë të njohura të thirrjes së procedurave (krahasuar me VB). Më tej ne do t'i trajtojmë vazhdimisht këto pyetje. Dhe tani ne paraqesim një përmbledhje të këshillave mbi këtë temë të formuluar nga Dan Appleman (versioni i tyre i parë u shfaq në 1993) me disa nga shtesat dhe komentet tona.

1. Mbani mend ByVal. Gabimi më i zakonshëm i bërë kur hyni në funksionet API dhe DLL është përdorimi i gabuar i fjalës kyçe ByVal: ata ose harrojnë ta vendosin atë, ose, anasjelltas, e vendosin kur nuk është e nevojshme.

Këta shembuj tregojnë efektin e operatorit ByVal në kalimin e parametrave

Lloji i parametrit	Me ByVal	Pa ByVal
Numër i plotë	Shty një numër të plotë 16-bitësh në pirg	Shtyhet në pirg adresën 32-bit të një numri të plotë 16-bit
E gjatë	Një numër i plotë 32-bit shtyhet në pirg	Shtyhet në pirg adresën 32-bit të një numri të plotë 32-bit
Varg	Vargu konvertohet në formatin e përdorur në C (të dhëna dhe një bajt null fundor). Adresa e linjës së re 32-bit shtyhet në pirg	Përshkruesi i linjës VB shtyhet në pirg. (Përshkrues të tillë nuk përdoren kurrë nga vetë API i Windows dhe njihen vetëm në DLL të implementuara posaçërisht për VB.)

Duhet të kujtojmë këtu se parametrat kalohen në çdo sistem programimi, përfshirë VB, në dy mënyra kryesore: me referencë (ByRef) ose me vlerë (ByVal). Në rastin e parë, adresa e ndryshores kalon (ky opsion përdoret si parazgjedhje në VB), në të dytën - vlera e saj. Dallimi themelor është se me anë të një referimi, vlera e ndryshuar e parametrit të kaluar kthehet në programin thirrës.

Për ta kuptuar, eksperimentoni me këto programe:

Dim v Si numër i plotë v = 2 Telefono MyProc (v) MsgBox “v =“ & v Nën MyProc (v Si numër i plotë) v = v + 1 Fund Sub

Duke ekzekutuar këtë shembull, do të merrni një mesazh me vlerën e variablit të barabartë me 3. Fakti është se në këtë rast adresa e ndryshores v, e krijuar fizikisht në programin thirrës, kalon në nënprogramin MyProc. Tani ndryshoni përshkrimin e procedurës në

Nën MyProc (ByVal v Si numër i plotë)

Si rezultat, gjatë ekzekutimit të testit, do të merrni v = 2, sepse vetëm vlera origjinale e ndryshores i kalohet procedurës - rezultati i operacioneve të kryera me të nuk kthehet në programin thirrës. Modaliteti i transferimit sipas vlerës gjithashtu mund të ndryshohet duke përdorur operatorin e thirrjes si më poshtë:

Nën MyProc (v Si numër i plotë) ... Thirrni MyProc ((v)) '(v) - kllapat tregojnë transferimin sipas modalitetit të vlerës _.

Megjithatë, kur i referohemi procedurave të brendshme VB, fjala kyçe ByVal nuk lejohet në deklaratën e thirrjes - në vend të kësaj përdoren kllapa. Ka një shpjegim për këtë.

Në rastin klasik (C, Fortran, Pascal), ndryshimi midis ByRef dhe ByVal varet nga ajo që saktësisht shtyhet në grumbullin e shkëmbimit të të dhënave - adresa e një ndryshoreje ose vlera e saj. Në Basic, versioni ByVal i emulimit të softuerit përdoret historikisht - adresa është gjithmonë në rafte, por vetëm kur kalohet nga vlera, krijohet një ndryshore e përkohshme për këtë. Për të dalluar këto dy opsione (Classic dhe Basic), përdoren mënyra të ndryshme të përshkrimit të modalitetit ByVal. Vini re se emulimi i modalitetit ByVal në VB siguron besueshmëri më të lartë të programit: duke ngatërruar formën e thirrjes, programuesi rrezikon vetëm që vlera e korrigjuar e variablit të kthehet (ose jo) në programin thirrës. Në versionin "klasik", një konfuzion i tillë mund të çojë në një gabim fatal gjatë ekzekutimit të procedurës (për shembull, kur në vend të një adrese memorie, përdoret një vlerë ndryshore e barabartë, të themi, zero).

Funksionet DLL zbatohen sipas parimeve "klasike" dhe prandaj kërkojnë një përshkrim të detyrueshëm se si shkëmbehen të dhënat me secilin prej argumenteve. Është për këtë qëllim që shërbejnë deklaratat e funksionit përmes përshkrimit Deklaroni (më saktë, një listë e argumenteve të kaluar). Më shpesh, kalimi i parametrave në një funksion të Windows API ose DLL bëhet duke përdorur fjalën kyçe ByVal. Për më tepër, ai mund të specifikohet si në deklaratën Declare ashtu edhe drejtpërdrejt kur thirret funksioni.

Pasojat e kalimit të gabuar të parametrave janë të lehta për t'u parashikuar. Nëse merrni një adresë qartësisht të pavlefshme, do t'ju kërkohet një mesazh GPF (General Protection Fault). Nëse funksioni merr një vlerë që përputhet me një adresë të vlefshme, atëherë funksioni API do të hyjë në zonën e dikujt tjetër (për shembull, kerneli i Windows) me të gjitha pasojat katastrofike që pasojnë.

2. Kontrolloni llojin e parametrave të kaluar. Numri i saktë dhe lloji i parametrave të kaluar janë po aq të rëndësishëm. Argumentet e deklaruara në Deklaratë duhet të përputhen me parametrat e pritur në funksionin API. Gabimi më i zakonshëm në kalimin e parametrave lidhet me ndryshimin midis vargjeve NULL dhe me gjatësi zero - mbani mend se ato nuk janë e njëjta gjë.

3. Kontrolloni llojin e kthimit.

VB është mjaft tolerant ndaj mospërputhjeve të tipit në vlerat e kthimit të funksioneve, pasi vlerat numerike zakonisht kthehen përmes regjistrave dhe jo përmes stivit. Rregullat e mëposhtme do t'ju ndihmojnë të përcaktoni vlerën e saktë të kthyer nga një funksion API:

• Një funksion DLL që nuk kthen një vlerë (analoge me void në 'C') duhet të deklarohet si një Nën VB.
• një funksion API që kthen një vlerë të plotë (Integer ose Long) mund të përkufizohet ose si një Nën ose një Funksion që kthen një vlerë të llojit të duhur.
• asnjë nga funksionet API nuk kthen numra me pikë lundruese, por disa DLL mund ta kthejnë këtë lloj të dhënash.

4. Përdorni konstruksionin "Si çdo" me shumë kujdes. Shumë funksione të Windows API kanë aftësinë të pranojnë parametra të llojeve të ndryshme dhe të përdorin konstruktin As Çdo (lloji interpretohet në varësi të vlerës së parametrave të tjerë të kaluar).

Një zgjidhje e mirë në këtë rast do të ishte përdorimi i pseudonimeve të shumëfishta të funksioneve, duke krijuar dy ose më shumë deklarata për të njëjtin funksion, ku secili nga përshkrimet specifikon parametrat e një lloji specifik.

5. Mos harroni të inicializoni vargjet. Ka shumë funksione në Win API që kthejnë informacionin duke ngarkuar të dhënat në buferat e vargjeve të kaluara si parametër. Në programin tuaj, mund të duket se bëni gjithçka siç duhet: mos harroni ByVal, kaloni saktë parametrat në funksion. Por Windows nuk mund të kontrollojë se sa e madhe është memoria e caktuar për vargun. Madhësia e linjës duhet të jetë mjaft e madhe për të akomoduar të gjitha të dhënat që mund të vendosen në të. Është përgjegjësi e programuesit VB të rezervojë një bufer të madhësisë së duhur.

Duhet të theksohet se në Windows 32-bit, gjatë përdorimit të vargjeve, konvertimi kryhet nga Unicode (kodimi me dy byte) në ANSI (një bajt) dhe anasjelltas, duke marrë parasysh cilësimet kombëtare të sistemit. Prandaj, ndonjëherë është më e përshtatshme të përdoren vargje bajt në vend të variablave të vargut për të rezervuar buferët. (Më shumë për këtë më poshtë.)

Më shpesh, funksionet Win API ju lejojnë të përcaktoni vetë madhësinë maksimale të bllokut. Në veçanti, ndonjëherë ju duhet të telefononi një funksion tjetër API për këtë, i cili do të "nxjejë" madhësinë e bllokut. Për shembull, GetWindowTextLength ju lejon të përcaktoni madhësinë e rreshtit të nevojshëm për të akomoduar titullin e dritares, i cili merret nga funksioni GetWindowText. Në këtë rast, Windows sigurohet që të mos shkoni jashtë vendit.

6. Sigurohuni që të përdorni Option Explicit.

7. Kontrolloni me kujdes vlerat e parametrave dhe ktheni vlerat. VB ka aftësi të mira të kontrollit të tipit. Kjo do të thotë që kur përpiqeni të kaloni një parametër të pavlefshëm në një funksion VB, gjëja më e keqe që mund të ndodhë është që të merrni një gabim nga VB. Por ky mekanizëm, për fat të keq, nuk funksionon kur hyni në funksionet e Windows API.

Windows 9x ka përmirësuar vlefshmërinë e parametrave për shumicën e funksioneve API. Prandaj, prania e një gabimi në të dhëna zakonisht nuk shkakton një gabim fatal, por nuk është aq e lehtë të përcaktohet se çfarë e ka shkaktuar atë.

Këtu mund të këshilloni përdorimin e disa mënyrave për të korrigjuar këtë lloj gabimi:

• përdorni modalitetin e korrigjimit me një hap ose komandën Debug.Print për të kontrolluar çdo thirrje të dyshimtë API. Kontrolloni rezultatet e këtyre thirrjeve për t'u siguruar që gjithçka është brenda kufijve normalë dhe funksioni ka përfunduar saktë;
• përdorni një korrigjues të Windows si CodeView dhe një korrigjues të Windows (i disponueshëm në Windows SDK). Këto mjete mund të zbulojnë gabimet e parametrave dhe të paktën të përcaktojnë se cili funksion API po e shkakton gabimin;
• përdorni mjete shtesë të palëve të treta për të kontrolluar llojet e parametrave dhe vlefshmërinë e vlerave të tyre. Mjete të tilla jo vetëm që mund të gjejnë gabime në parametra, por edhe të tregojnë linjën e kodit VB ku ka ndodhur gabimi.

Përveç kësaj, është e domosdoshme të kontrolloni rezultatin e funksionit API.

8. Mos harroni se numrat e plotë në VB dhe Windows nuk janë e njëjta gjë. Para së gjithash, duhet të kihet parasysh se termi "Integer" në VB nënkupton një numër 16-bit, në dokumentacionin Win 32 - 32-bit. Së dyti, numrat e plotë (Integer dhe Long) në VB janë sasi të nënshkruara (d.m.th., një shifër përdoret si shenjë, pjesa tjetër përdoret si mantisa e një numri), në Windows përdoren vetëm numra jo negativë. Kjo rrethanë duhet të kihet parasysh kur formoni parametrin e kaluar duke përdorur veprime aritmetike (për shembull, llogaritja e adresës duke shtuar disa bazë dhe kompensim). Funksionet standarde aritmetike VB nuk janë të përshtatshme për këtë. Si të jemi në këtë rast, ne do të flasim veçmas.

9. Kushtojini vëmendje emrave të funksioneve. Ndryshe nga Win16, emrat e të gjitha funksioneve të Win32 API janë të ndjeshëm ndaj përdorimit të saktë të shkronjave të mëdha dhe të vogla (gjë që nuk ishte rasti në Win16). Nëse përdorni diku një shkronjë të vogël në vend të një shkronje të madhe ose anasjelltas, atëherë funksioni i kërkuar nuk do të gjendet. Gjithashtu sigurohuni që të përdorni saktë prapashtesën A ose W në funksionet që përdorin parametrat e vargut. (Shih më poshtë për më shumë për këtë.)

10. Ruani punën tuaj më shpesh. Gabimet që lidhen me përdorimin e gabuar të DLL dhe Win API mund të çojnë në një ndërprerje jonormale të mjedisit VB, dhe ndoshta të gjithë sistemit operativ. Duhet të siguroheni që kodi që shkruani të ruhet përpara ekzekutimit të testit. Gjëja më e thjeshtë është të vendosni mënyrën e regjistrimit automatik të moduleve të projektit përpara se të filloni projektin në mjedisin VB.

Pasi të keni lexuar këshillën e mëparshme, mund të mendoni se përdorimi i funksioneve Win API është një biznes i rrezikshëm. Në një farë mase, kjo është e vërtetë, por vetëm në krahasim me programimin e sigurt të ofruar nga vetë VB. Por me aplikimin e tyre të aftë dhe njohjen e kurtheve të mundshme, ky rrezik është minimal. Për më tepër, shpesh është thjesht e pamundur të braktisësh plotësisht përdorimin e Win API - ato do të kërkohen akoma për çdo zhvillim serioz.

Përveç kësaj, më herët kemi përmendur kurthet për një klasë të gjerë të DLL-ve. Në rastin e Win API, gjithçka është shumë më e thjeshtë, pasi forma e thirrjes së këtyre funksioneve është qartë e unifikuar këtu. Në këtë rast, pikat kryesore të mëposhtme duhet të merren parasysh:

1. Funksionet e Win32 API janë vetëm funksione, domethënë procedura të tipit Function (ka pasur shumë Subs në Win16 API). Të gjitha këto janë funksione të tipit Long, kështu që përshkrimet e tyre shkruhen në formën e mëposhtme: Deklaroni emrin e funksionit ... Përderisa 'lloji i funksionit _ përcaktohet në mënyrë eksplicite

   Deklarimi i emrit të funksionit dhe 'lloji i funksionit _ përcaktohet me një prapashtesë

   Një thirrje për një funksion API duket si kjo:

Rezultati & = ApiEmri & ([ Lista e argumenteve]

1. Më shpesh, vlera e kthyer e një funksioni është një kod daljeje operacioni. Për më tepër, një vlerë jo zero do të thotë në këtë rast një përfundim normal, një vlerë zero do të thotë një gabim. Zakonisht (por jo gjithmonë) ju mund të sqaroni natyrën e gabimit duke thirrur funksionin GetLastError. Përshkrimi i këtij funksioni duket si ky: Deklaroni funksionin GetLastError & Lib "kernel32" ()

   KUJDES! Kur punoni në VB, është më mirë të përdorni veçorinë LastDLLError të objektit Err për të marrë vlerën e kodit të gabimit të kualifikuar, sepse ndonjëherë VB do të rivendosë funksionin GetLastError midis thirrjes API dhe vazhdimit të ekzekutimit të programit.

   Ju mund të interpretoni kodin e kthyer nga GelLastError duke përdorur konstantat e shkruara në skedarin API32.TXT, me emra që fillojnë me prapashtesën ERROR_.

   Gabimet më të zakonshme kanë kodet e mëposhtme:

   • ERROR_INVALID_HANDLE = 6 & - dorezë e pavlefshme
   • ERROR_CALL_NOT_IMPLEMENTED = 120 & - telefononi në Windows 9x një funksion të disponueshëm vetëm për Windows NT
   • ERROR_INVALID_PARAMETER = 87 & - vlerë e pavlefshme e parametrit

   Megjithatë, shumë funksione kthejnë vlerën e disa parametrave të kërkuar (për shembull, OpenFile kthen një vlerë të përshkruesit të skedarit). Në raste të tilla, gabimi identifikohet nga ndonjë vlerë tjetër e veçantë Kthimi &, më shpesh 0 ose –1.

2. API-të Win32 përdorin mënyra rreptësisht të fiksuara për të kaluar llojet më të thjeshta të të dhënave. a) ByVal ... Për sa kohë

   Variablat e gjata bëjnë të paktën 80% të kalimit të argumentit. Vini re se argumenti gjithmonë e ndjekur nga fjala kyçe ByVal, e cila, ndër të tjera, do të thotë se kryhet një transferim i të dhënave në një drejtim - nga një program VB në një funksion API.

   B) ByVal ... As String

   Ky lloj transferimi i të dhënave gjithashtu ndodh mjaft shpesh, dhe gjithashtu me një argument gjithmonë Aplikohet ByVal. Kur thirret funksioni API, adresa e vargut shkruhet në stek, kështu që në këtë rast, shkëmbimi i të dhënave në dy drejtime është i mundur. Ka disa gracka që duhen marrë parasysh kur punoni me vargje.

   Së pari, memoria për një varg rezervohet në programin thirrës, kështu që nëse funksioni API mbush vargje, atëherë duhet të krijoni një varg të madhësisë së kërkuar përpara se ta thërrisni. Për shembull, funksioni GetWindowsDirectory kthen shtegun për në direktorinë e Windows, i cili sipas definicionit nuk duhet të jetë më i gjatë se 144 karaktere. Prandaj, një thirrje në këtë funksion duhet të duket diçka si kjo:

   WinPath $ = Hapësirë ​​$ (144) 'rezervoni një varg prej _ 144 karakteresh Rezultati & = GetWindowsDirectory & (WinTath $, 144) _' mbushni bufferin 'Rezultati & - numri aktual i karaktereve në emrin e drejtorisë _ WinPath $ = Majtas $ (WinPath, rezultati dhe)

   Problemi i dytë është se kur thirret funksioni API, vargu origjinal konvertohet në ndonjë paraqitje të brendshme, dhe kur funksioni del, anasjelltas. Nëse në ditët e Win16 ky operacion konsistonte vetëm në shtimin e një bajt zero në fund të një vargu, atëherë me ardhjen e Win32, kjo u plotësua nga transformimi i kodimit të Unicode me dy bajt në ANSI dhe anasjelltas. (Kjo u diskutua në detaje në artikullin "Veçoritë e punës me variablat e vargut në VB", ComputerPress 10'99 dhe 01'2000). Tani për tani, le të vërejmë vetëm se duke përdorur ByVal ... Si ndërtim String, ju mund të shkëmbeni vargje vetëm me të dhëna karakteresh.

   B) ... Si Çdo

   Kjo do të thotë që disa adresa të buferit të memories do të shtyhen në stek, përmbajtja e së cilës do të interpretohet nga funksioni API, për shembull, në varësi të vlerës së argumenteve të tjera. Sidoqoftë, As Any mund të përdoret vetëm në një deklaratë Declare - për një thirrje specifike në një funksion, një variabël specifik duhet të përcaktohet si argument.

   D) ... As UserDefinedType

   Ky dizajn përdoret gjithashtu shpesh kur është e nevojshme të shkëmbehen të dhëna (përgjithësisht në të dy drejtimet) duke përdorur një strukturë. Në fakt, ky konstruksion është një lloj zbatimi konkret i formës së transmetimit As Çdo, por në këtë rast, funksioni është konfiguruar për një strukturë fikse.

   Forma e strukturës së të dhënave përcaktohet nga një funksion specifik API, dhe është përgjegjësi e programuesit që ta përshkruajë dhe rezervojë saktë atë në programin thirrës. Ky dizajn gjithmonë përdorur nga pa fjalët ByVal, domethënë, në këtë rast, kryhet transferimi me referencë - adresa e ndryshores shkruhet në pirg.

Një shembull i thirrjes së një funksioni API

Le të ilustrojmë sa më sipër me një shembull të përdorimit të dy funksioneve të dobishme për të punuar me skedarë - lopen dhe lread, të cilat përshkruhen si më poshtë:

Deklaroni funksionin lopen Lib "kernel32" _ Pseudonimi "_lopen" (_ ByVal lpFileName As String, _ ByVal wReadWrite Sa Long) Për aq kohë sa Deklaroni Funksionin lread Lib "kernel32" _ Pseudonimi "_lread" (_ ByVal Long, h File lpBuffer si çdo, _ ByVal wBytes për aq kohë sa) Për sa kohë

Në VB, homologët e tyre - në këtë rast, ato të sakta - janë deklaratat Open dhe Get (për modalitetin Binary). Le t'i kushtojmë vëmendje menjëherë përdorimit të fjalës kyçe Alias ​​në një deklaratë funksioni - ky është pikërisht rasti kur nuk mund të bëni pa të. Emrat e funksioneve reale në bibliotekë fillojnë me një nënvizim (stili tipik C), i cili nuk lejohet në VB.

Operacioni për hapjen e një skedari mund të duket si ky:

Const INVALID_HANDLE_VALUE = -1 'e pavlefshme _ vlera e përshkruesit lpFileName $ = "D: \ calc.bas"' emri i skedarit wReadWrite & = 2 'modaliteti leximi-shkruaj hFile & = hap (lpFileName $, wReadWrite &) përcakto skedarin nëse define hFile & = INVALID_HANDLE_VALUE Pastaj _ 'gabim në hapjen e skedarit' sqaroni kodin e gabimit CodeError & = Err.LastDllError 'CodeError & = GetLastError _' ky konstruksion nuk funksionon Përfundoni nëse

Këtu duhen theksuar dy pika:

• si vlerë e funksionit, marrim vlerën e përshkruesit të skedarit. Gabimi korrespondon me vlerën –1;
• vetëm në këtë rast, thirrja në funksionin GetLastError nuk funksionon - për të marrë vlerën e specifikuar të gabimit, ne iu drejtuam objektit Err (për mundësinë e një situate të tillë folëm më lart).

Më pas mund të lexoni përmbajtjen e skedarit, por kjo supozon se programuesi duhet të ketë njëfarë kuptimi të strukturës së tij (ashtu siç bën kur punon me binarët arbitrarë). Në këtë rast, një thirrje në funksionin lread mund të duket kështu:

Dim MyVar As Single wBytes = lread (hFile &, MyVar, Len (MyVar) 'lexo numrin real, 4 bytes' wBytes - numri i të dhënave të lexuara në të vërtetë,' -1 - gabim ... Shkruani MyStruct x Si Single i Si fund të numrit të plotë Shkruani Dim MyVar si MyStruct wBytes = lread (hFile &, MyVar, Len (MyVar)) 'lexo strukturën e të dhënave, 6 byte

Shënim përsëri: argumenti i funksionit të dytë kalohet me referencë, pjesa tjetër kalohet nga vlera.

Dim MyVar As String MyVar = Hapësirë ​​$ (10) 'rezervoni një variabël për 10 karaktere wBytes = lread (hFile &, ByVal MyVar, Len (MyVar))' lexoni një varg karakteresh, 10 karaktere

Këtu mund të shihni një ndryshim të rëndësishëm nga shembulli i mëparshëm - ndryshorja e vargut shoqërohet domosdoshmërisht me fjalën kyçe ByVal.

Leximi i përmbajtjes së një skedari në një grup (për thjeshtësi, ne do të përdorim një grup bajt njëdimensional) bëhet si më poshtë:

Dim MyArray (1 deri në 10) Si byte wBytes = lread (hFile &, MyArray (1), _ Len (MyArray (1)) * 10) 'lexoni 10 elemente të grupit

Duke specifikuar elementin e parë të grupit si argument, ne po kalojmë adresën e fillimit të zonës së kujtesës të rezervuar për grupin. Natyrisht, çdo fragment i grupit mund të plotësohet në këtë mënyrë:

WBytes = lread (hFile &, MyArray (4), _ Len (MyArray (1)) * 5) 'lexoni elementet e grupit 4 deri në 8

Këshillë 5. Përdorni pseudonimin për ingranazhet dhe parametrat Si Çdo

Këtu, bazuar në shembullin e mëparshëm, ne do të zbulojmë thelbin e këshillës së katërt të Dan Appleman.

Kur punoni me funksionin lread, mbani mend se kur e përdorni atë duke përdorur një variabël string, duhet të përdorni fjalën kyçe ByVal (përndryshe, mesazhi për një operacion të paligjshëm nuk mund të shmanget). Për të qenë në anën e sigurt, mund të bëni një përshkrim të veçantë shtesë të të njëjtit funksion për të punuar vetëm me variablat e vargut:

Deklaroni funksionin lreadString Lib "kernel32" _ pseudonimi "_lread" (_ ByVal hFile për aq kohë sa, ByVal lpBuffer si varg, _ ByVal wBytes për aq kohë sa)

Kur punoni me këtë përshkrim, nuk keni më nevojë të specifikoni ByVal kur përdorni:

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

Duket se sintaksa e deklaratës Declare ju lejon të bëni një përshkrim të ngjashëm të veçantë për një grup:

Deklaroni funksionin lreadString Lib "kernel32" Pseudonimi "_lread" (_ ByVal hFile për aq kohë sa, lpBuffer () si byte, _ ByVal wBytes për aq kohë sa)

Megjithatë, ankesa

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

në mënyrë të pashmangshme çon në një gabim fatal të programit.

Ky është një vazhdim i bisedës rreth veçorive të përpunimit të variablave të vargut në Visual Basic: VB përdor një kodim Unicode me dy byte, Win API - një ANSI me një bajt (dhe me formatin e pranuar në C - me një bajt zero në fund). Prandaj, kur përdoren variablat e vargut si argument, konvertimi nga Unicode në ANSI kryhet gjithmonë automatikisht kur thirret një funksion API (më saktë, një funksion DLL) dhe konvertimi i kundërt kryhet në kthim.

Zgjidhja nga kjo është e thjeshtë: duke përdorur variablat String mund të shkëmbeni të dhëna karakteresh, por nuk mund t'i përdorni ato për të shkëmbyer informacione arbitrare binar (siç ishte rasti me versionet 16-bit të VB). Në rastin e fundit, është më mirë të përdorni një grup bajtësh njëdimensional.

Siç e dini, lloji String mund të përdoret për të përshkruar një strukturë të personalizuar. Në këtë drejtim, duhet mbajtur mend sa vijon:

• Është kategorikisht e pamundur të përdoret konstruksioni i mëposhtëm për t'iu referuar API-së Win: Shkruani MyStruct x Si Single s As String 'variable gjatësi vargu Lloji i fundit

  Në rastin e një vargu me gjatësi të ndryshueshme, një përshkrues i vargut kalon si pjesë e strukturës me të gjitha pasojat që pasojnë në formën e një gabimi të ekzekutimit të programit.

• Ju mund të përdorni një varg me gjatësi fikse si një element strukture: Lloji MyStruct x Si Single s As String * 8 'vargu me gjatësi fikse Lloji i fundit

Në këtë rast, kryhet konvertimi përkatës i kodimeve.

Dhe shënimi i fundit: në asnjë rast nuk mund të përdorni një grup variablash vargu (gjatësi fikse dhe të ndryshueshme) kur thërrisni një funksion API. Në të kundërt do të garantohet shfaqja e një “operacioni të paligjshëm”.

Ka shumë të ngjarë që do të hasni në një situatë ku duhet të shkruani funksionet tuaja DLL. Nevoja për këtë do të shfaqet në mënyrë të pashmangshme nëse përdorni teknologji të përzier programimi - përdorimi i dy ose më shumë gjuhëve të programimit për të zbatuar një aplikacion.

Vini re në këtë drejtim se programimi i përzier është mjaft i zakonshëm për një aplikim mjaft kompleks. Në të vërtetë, çdo gjuhë (më saktë, një sistem programimi i bazuar në gjuhë) ka pikat e forta dhe të dobëta të veta, kështu që është mjaft logjike të përdoren avantazhet e mjeteve të ndryshme për të zgjidhur probleme të ndryshme. Për shembull, VB - për krijimin e një ndërfaqeje përdoruesi, C - për qasje efikase në burimet e sistemit, Fortran - për zbatimin e algoritmeve numerike.

Mendimi i autorit është se çdo programim serioz kërkon që zhvilluesi të zotërojë të paktën dy mjete. Sigurisht, në kushtet moderne të një ndarjeje të qartë të punës, është shumë e vështirë të jesh një ekspert i shkëlqyer edhe në dy sisteme, ndaj skema e “gjuhëve kryesore dhe ndihmëse” është më e logjikshme. Ideja këtu është se edhe një njohje sipërfaqësore e gjuhës "ndihmëse" (shkrimi i procedurave mjaft të thjeshta) mund të rrisë shumë efektivitetin e gjuhës "kryesore". Vini re se njohja e VB, të paktën si ndihmëse, është sot një kërkesë pothuajse e detyrueshme për një programues profesionist. Nga rruga, në ditët e DOS për çdo programues, duke përfshirë Basic, ishte shumë e dëshirueshme të njiheshin bazat e Assembler.

Në një mënyrë apo tjetër, por edhe në kushtet e punës në grup, kur secili programues është i angazhuar në biznesin e tij specifik, të gjithë pjesëmarrësit e projektit duhet të kenë një ide për veçoritë e ndërfaqes procedurale në gjuhë të ndryshme. Dhe të dini se shumë sisteme programimi (përfshirë VB), përveç ndërfaqes së paracaktuar, ju lejojnë të përdorni metoda të tjera, të zgjeruara të referimit në procedura, të cilat bëjnë të mundur përshtatjen e ndërfaqes me një gjuhë tjetër.

Kur studioni ndërfaqen ndërprocedurale, duhet t'i kushtoni vëmendje kurthet e mëposhtme të mundshme:

• Gjuhë të ndryshme mund të përdorin konventa të ndryshme për mënyrën e shkrimit të identifikuesve. Për shembull, një nënvizim përdoret shpesh në fillim të emrit të procedurës, i cili është i ndaluar në VB. Ky problem zgjidhet lehtësisht duke përdorur fjalën kyçe Alias ​​në deklaratën Declare (shih shembullin këshillë 2.3).
• Mund të përdoret një sekuencë e ndryshme e shkrimit të argumenteve të kaluara në pirg. Për shembull, në ditët e DOS (sinqerisht nuk e di se si duket tani në Windows), C shkroi argumentet nga fundi i listës, gjuhët e tjera (Fortran, Pascal, Basic) - që nga fillimi.
• Si parazgjedhje, përdoren parime të ndryshme të kalimit të parametrave - me referencë ose me vlerë.
• Parime të ndryshme të ruajtjes së variablave të vargut. Për shembull, në C (si dhe në Fortran dhe Pascal) gjatësia e një vargu përcaktohet nga një bajt zero në fund të tij, ndërsa në Basic gjatësia shkruhet në mënyrë eksplicite në përshkruesin e vargut. Sigurisht, duhet të keni parasysh mundësinë e përdorimit të kodimeve të ndryshme të karaktereve.
• Kur transferoni vargje shumëdimensionale, mbani mend se ekzistojnë opsione të ndryshme për shndërrimin e strukturave shumëdimensionale në njëdimensionale (duke filluar nga indeksi i parë ose nga i fundit, në lidhje me grupet dydimensionale - "sipas rreshtave" ose "sipas kolonave").

Duke marrë parasysh të gjitha këto, rekomandimet e mëposhtme mund të formulohen:

• Përdorni mënyrat më të thjeshta dhe të provuara për të kaluar argumente te funksionet DLL. Standardet e miratuara për Win API janë shembuj të mirë.
• Në asnjë rrethanë mos kaloni vargje të variablave të vargut.
• Përdorni kalimin me shumë kujdes të variablave të vargut të thjeshtë dhe vargjeve shumëdimensionale.
• Sigurohuni që të kontrolloni posaçërisht funksionalitetin e mekanizmit për kalimin e argumenteve në dhe nga procedura e thirrur. Shkruani një test të personalizuar për të testuar transmetimin e të dhënave. Kontrolloni veçmas nëse çdo argument është kaluar saktë. Për shembull, nëse keni një procedurë me disa argumente, fillimisht kontrolloni që çdo parametër të kalojë saktë për një variant me një argument, dhe vetëm atëherë për të gjithë listën.

Por, çka nëse funksioni DLL është shkruar tashmë, për shembull, në Fortran, por ndërfaqja e tij hyrëse nuk përshtatet mirë me standardet e mësipërme VB? Ka dy këshilla për të dhënë këtu. Së pari, shkruani një funksion provë DLL dhe përdorni atë për të provuar të gjeni thirrjen e duhur nga programi VB me provë dhe gabim. Së dyti: shkruani një procedurë përshtatës në të njëjtin Fortran që do të siguronte një ndërfaqe të thjeshtë midis VB dhe një funksioni DLL me konvertimin e strukturave të thjeshta të të dhënave në ato komplekse (për shembull, konvertimi i një grupi bajtesh shumëdimensional në një grup vargjesh).

Pra: përdorni funksionet DLL. Por qëndroni vigjilent...

ComputerPress 9 "2000

API përcakton funksionalitetin që ofron programi (moduli, biblioteka), ndërsa API ju lejon të abstragoni se si zbatohet saktësisht ky funksionalitet.

Nëse një program (modul, bibliotekë) konsiderohet si një kuti e zezë, atëherë API është një grup "pullash" që janë në dispozicion të përdoruesit të kësaj kutie, të cilat ai mund t'i rrotullojë dhe tërheqë.

Komponentët e softuerit ndërveprojnë me njëri-tjetrin përmes API-ve. Në këtë rast, komponentët zakonisht formojnë një hierarki - komponentët e nivelit të lartë përdorin API-në e komponentëve të nivelit të ulët, dhe ata, nga ana tjetër, përdorin API-në e komponentëve edhe të nivelit më të ulët.

Sipas këtij parimi, protokollet e transferimit të të dhënave ndërtohen. Protokolli standard i Internetit (modeli i rrjetit OSI) përmban 7 shtresa (nga shtresa fizike e transmetimit të paketave të biteve deri te shtresa e protokolleve të aplikacionit si HTTP dhe IMAP). Çdo shtresë përfiton nga funksionaliteti i shtresës së mëparshme të transferimit të të dhënave dhe, nga ana tjetër, ofron funksionalitetin e dëshiruar në shtresën tjetër.

Është e rëndësishme të theksohet se koncepti i një protokolli është i afërt në kuptim me konceptin e një API. Të dyja janë abstraksione të funksionalitetit, vetëm në rastin e parë po flasim për transferimin e të dhënave, dhe në të dytën - për ndërtimin e aplikacioneve kompjuterike.

API-ja e bibliotekës së funksioneve dhe klasave përfshin një përshkrim nënshkrime dhe semantika e funksionit.

Ndërfaqja e programimit të aplikacionit (API) është një ndërfaqe programimi për ndërveprimin midis sistemeve që lejon:

• Qasuni në shërbimet e biznesit të ndërmarrjeve
• Shkëmbeni informacionin midis sistemeve dhe aplikacioneve
• Thjeshtoni ndërveprimet midis kompanive, partnerëve, zhvilluesve dhe klientëve

Hapni strategjinë API

Strategjia API përfshin:

• Zhvillimi i produkteve të biznesit bazuar në API-të ekzistuese
• Ofrimi i shërbimeve të brendshme për zhvilluesit
• Modelet e fitimit të parave të API për ndërtimin e ndërveprimeve shumëkanale dhe rritjen e fitimeve

Zbatimi i konceptit Open API ndihmon në transformimin e një biznesi, futjen e tij në një ekosistem fleksibël të projektit të aktorëve të tregut, krijimin e kushteve për gjenerimin e vazhdueshëm të ideve të reja dhe formimin e vlerave shtesë në menaxhimin e grupeve të të dhënave të korporatës.

Tregu për zgjidhjet e integrimit po zhvillohet në kontekstin e evolucionit të API-ve - nga EDI dhe SOAP në Web 2.0, i cili filloi epokën e API-ve publike. Numri i ndërfaqeve të tilla në 3 vitet e ardhshme mund të rritet më shumë se 50 herë dhe të arrijë në 1 milion. Kjo është për shkak të shumëkanaleve: kanalet e ndërveprimit me klientët duhet të ndryshojnë me ta. Rritja e vazhdueshme e numrit të konsumatorëve dhe vëllimit të të dhënave ka çuar në shfaqjen e ekonomisë API, e cila ndihmon në krijimin e modeleve inovative të biznesit për përdorimin e aseteve dhe shërbimeve të ndërmarrjes bazuar në ndërfaqe të hapura.

Nënshkrimi i funksionit

Nënshkrimi i funksionit- pjesë e një deklarate të përgjithshme funksioni që lejon transmetuesit të identifikojnë funksionin ndër të tjera. Gjuhë të ndryshme programimi kanë ide të ndryshme për nënshkrimin e një funksioni, gjë që lidhet ngushtë edhe me mundësitë e mbingarkesës së funksionit në këto gjuhë.

Ndonjëherë dalloni nënshkrimi i thirrjes dhe nënshkrimi i zbatimit funksione. Nënshkrimi i thirrjes zakonisht ndërtohet nga struktura sintaksore e një thirrjeje funksioni, duke marrë parasysh nënshkrimin e fushës së funksionit të dhënë, emrin e funksionit, sekuencën e llojeve aktuale të argumenteve në thirrje dhe llojin e rezultat. Nënshkrimi i zbatimit zakonisht përfshin disa elemente nga ndërtimi sintaksor i një deklarate funksioni: specifikuesi i fushës së funksionit, emri i tij dhe sekuenca e llojeve të argumenteve formale.

Për shembull, në gjuhën e programimit C ++, një funksion i thjeshtë njihet pa mëdyshje nga përpiluesi me emrin e tij dhe sekuencën e llojeve të argumenteve të tij, që përbën nënshkrimin e funksionit në këtë gjuhë. Nëse funksioni është një metodë e ndonjë klase, atëherë emri i klasës do të përfshihet gjithashtu në nënshkrim.

Duhet të theksohet gjithashtu se një programues shpesh ka në dispozicion disa API të ndryshme që lejojnë arritjen e të njëjtit rezultat. Sidoqoftë, çdo API zakonisht zbatohet duke përdorur API-në e komponentëve të softuerit të një niveli më të ulët abstraksioni.

Për shembull: për të parë rreshtin "Përshëndetje, botë!" gjithçka që duhet të bëni është të krijoni një dokument HTML me një titull minimal dhe një trup të thjeshtë që përmban vargun e dhënë. Çfarë ndodh kur shfletuesi hap këtë dokument? Programi i shfletuesit do të transferojë emrin e skedarit (ose një përshkrues skedari tashmë të hapur) në bibliotekën që përpunon dokumentet HTML, e cila, nga ana tjetër, duke përdorur API të sistemit operativ, do ta lexojë këtë skedar dhe do të kuptojë pajisjen e tij, do të thërrasë operacione si "Pastro dritaren", "shkruani me fontin e zgjedhur Hello, world!" this".

Në të njëjtën kohë, praktikisht në secilin prej niveleve, ekzistojnë në fakt disa API të mundshme alternative. Për shembull: ne mund të shkruajmë dokumentin origjinal jo në HTML, por në LaTeX, për shfaqje mund të përdorim çdo shfletues. Shfletues të ndryshëm në përgjithësi përdorin biblioteka të ndryshme HTML, dhe për më tepër, të gjitha mund të kompilohen (në përgjithësi) duke përdorur biblioteka të ndryshme primitive dhe në sisteme të ndryshme operative.

Sfidat kryesore të sistemeve ekzistuese API me shtresa janë kështu:

• Kompleksiteti i transferimit të kodit të programit nga një sistem API në tjetrin (për shembull, kur ndryshoni OS);
• Humbja e funksionalitetit kur kaloni nga një nivel më i ulët në një më të lartë. Përafërsisht, çdo "shtresë" e API-së është krijuar për të lehtësuar disa grupe standarde të operacioneve. Por në të njëjtën kohë, bëhet vërtet e vështirë, ose bëhet thelbësisht e pamundur të kryhen disa operacione të tjera që ofrohen nga një nivel më i ulët API.

Llojet bazë të API-ve

API e brendshme

• Qasja në API ofrohet vetëm për zhvilluesit e brendshëm
• Aplikime që synojnë punonjësit e ndërmarrjes

Drejtuesit e biznesit:

• Konsistenca e zhvillimit
• Kostot e reduktuara
• Përmirësimi i efikasitetit të zhvillimit

API-të e partnerëve

• API-të janë të disponueshme vetëm për një grup të kufizuar partnerësh biznesi
• Aplikacionet janë të destinuara për konsumatorët fundorë dhe përdoruesit e biznesit

Drejtuesit e biznesit:

• Automatizimi i procesit të zhvillimit
• Zhvillimi i partneriteteve
• Optimizimi i procesit të ndërveprimit me partnerët

API-të publike

Qasja i ofrohet çdo zhvilluesi të jashtëm. Aplikacionet u drejtohen përdoruesve fundorë

Drejtuesit e biznesit:

• Zhvillimi i shërbimeve të reja
• Zhvillimi i ekosistemit
• Ndërveprim shumëkanalësh

API-të më të famshme

API për sistemet operative

GUI API

• Direct3D (pjesë e DirectX)
• DirectDraw (pjesë e DirectX)

Ju mund të përjetoni gëzim dhe zhgënjim kur punoni me një API. Nga njëra anë, duke ndërvepruar me aplikacione të tjera, ju mund të rrisni shumë shtrirjen e audiencës dhe efektin "wow" të aplikacionit tuaj. Nga ana tjetër, kjo përfshin leximin e një sërë dokumentacioni, mësimin rreth strategjive të vërtetimit dhe analizimin e mesazheve të gabimit joinformativ (ose edhe të humbur).

Para së gjithash, nëse ende nuk e kuptoni plotësisht se çfarë është një API (Application Programming Interface), lexoni shpjegimin e Skillcrush dhe më pas pjesën e parë të këtij artikulli për të kapur hapin.

"API" është një koncept tepër i gjerë - sa herë që aplikacioni juaj "flet" me një aplikacion tjetër, kjo ndodh përmes një API. Komponentët brenda aplikacionit tuaj, si pjesë të ndryshme të Rails, gjithashtu komunikojnë me njëri-tjetrin nëpërmjet API-ve. Ato janë pak a shumë nën-aplikacione të pavarura që përcjellin të dhënat që secilit prej tyre i nevojiten për të kryer detyrat e veta specifike. Në botën e aplikacioneve, gjithçka është API!

Kur krijoni aplikacione me funksione më dinamike të pjesës së përparme (si aplikacione Javascript me një faqe, ashtu edhe aplikacione të thjeshta me thirrje të veçanta AJAX), ato do të komunikojnë me prapavijën e Rails përmes API-së tuaj, që është në të vërtetë vetëm disa rreshta kodi shtesë. duke u treguar kontrollorëve tuaj se si të shërbejnë JSON ose XML në vend të HTML.

Në këtë tutorial, do të mësoni se si të krijoni API-në tuaj. Në mësimet vijuese, ne do të theksojmë se si të ndërveprojmë me API-të nga aplikacionet e tjera. Mësimet duhet të jenë një trampolinë e mirë për të mësuar këtë temë, por ato nuk kanë gjasa të jenë në gjendje të mbulojnë plotësisht të gjitha rastet. Shumica e punës me API-të është të dish se si të lexosh dokumentacionin e tyre dhe të kuptosh se çfarë duan nga ju.

Pika për të menduar

Rishikoni pyetjet dhe shikoni nëse i dini përgjigjet. Kontrolloni veten përsëri pasi të keni përfunduar detyrën.

• Si Rails kupton se çfarë lloj skedari prisni si përgjigje kur bëni një kërkesë HTTP.
• Cili është qëllimi i metodës #reagoj_to?
• Si e ktheni një objekt Përdoruesi ndërkohë që specifikoni atributet që nuk dëshironi të përfshihen në atë objekt (d.m.th., nuk mund të ktheni thjesht User.first)?
• Cilat janë 2 hapat në prapaskenë të metodës #to_json?
• Si t'i them veprimit të kontrolluesit që të japë vetëm mesazhin e gabimit?
• Si mund të krijoj mesazhin tim të gabimit?
• Pse nuk mund të përdorni metoda të vërtetimit të kontrolluesit të bazuara në sesion nëse doni të lejoni lidhje programatike me API-në tuaj?
• Çfarë është arkitektura e orientuar drejt shërbimit?

Bazat e API

Aplikacioni juaj Rails është në fakt tashmë një API, megjithëse mund të mos e mendoni si një API. Shfletuesi i uebit që përdorin përdoruesit tuaj është gjithashtu një program, kështu që në fakt bën një kërkesë API në aplikacionin tuaj Rails kur përdoruesi hap një faqe të re. Dikur mendonim në këtë mënyrë, sepse përkthimi i shablloneve HTML është një detyrë kaq e zakonshme saqë ne thjesht e kodojmë këtë funksionalitet në programet tona të serverit si një lloj përgjigjeje standarde, dhe ne e konsiderojmë çdo gjë tjetër si të pazakontë.

Megjithatë, shpesh herë ju dëshironi të bëni një kërkesë që nuk kërkon që ju të kaloni nëpër të gjitha dhimbjet e kokës së përdorimit të shfletuesit tuaj. Ju mund të mos kujdeseni për strukturën e faqes (HTML), por dëshironi të dhëna të pastra në këmbim. Le të themi se dëshironi të merrni një listë të të gjithë përdoruesve. Ju mund të kërkoni diçka si http://yourapplication.com/users, e cila ka shumë të ngjarë të shkaktojë një veprim #index dhe të japë një listë të të gjithë përdoruesve në aplikacion.

Por pse të shqetësoheni me gjithë këtë informacion të panevojshëm kur gjithçka që dëshironi është të merrni një listë të përdoruesve? Opsioni më i lehtë do të ishte dërgimi i një kërkese në të njëjtën URL, duke specifikuar një pritje të një përgjigjeje JSON ose XML në këmbim. Nëse e konfiguroni saktë kontrolluesin tuaj Rails, do të merrni përsëri një objekt të thjeshtë të grupit JSON që përmban të gjithë përdoruesit. E mrekullueshme!

I njëjti parim zbatohet kur komunikoni me një API të jashtëm. Le të themi se dëshironi të merrni "tweet"-et e fundit të një përdoruesi nga Twitter. E tëra çfarë ju duhet të bëni është t'i tregoni aplikacionit tuaj Rails se si të ndërveprojë me API-në e Twitter (d.m.th., të vërtetohet vetë), të paraqesë kërkesën dhe të përpunojë grupin e tweet-eve që kthehen.

Krijimi i API

Ju mund të dëshironi ta bëni aplikacionin tuaj Rails një sfond të pastër API për faqet e internetit të përparme, ose thjesht mund të dëshironi të mësoni se si të dërgoni JSON kur pjesa e përparme e kërkon atë. Ky seksion nuk do të mbulojë mënyrën e krijimit të API-ve të plota RESTful me funksionalitetin e vërtetimit. Kjo është një hyrje e qetë për trajtimin e aplikacionit tuaj si një API.

Bazat

Nëse dëshironi që aplikacioni juaj Rails të kthejë JSON në vend të HTML, duhet t'i tregoni kontrolluesit që ta bëjë këtë. Gjëja më e mirë është se i njëjti veprim i kontrolluesit mund të kthejë lloje të ndryshme në varësi të faktit nëse përdoruesi juaj po bën një kërkesë të rregullt nga shfletuesi ose po hyn në API përmes linjës së komandës. Kjo përcakton se çfarë lloj kërkese është bërë bazuar në zgjerimin e skedarit të kërkuar, për shembull shembull.xml ose example.json.

Ju mund të kontrolloni se çfarë "mendon" Rails për llojin e skedarit që prisni duke kontrolluar regjistrin e serverit:

Filloi GET "/ postime / të reja" për 127.0.0.1 në 2013-12-02 15:21:08 -0800 Përpunimi nga PostsController # i ri si HTML

Rreshti i parë ju tregon se cila URL është kërkuar, dhe e dyta ju tregon se ku është drejtuar dhe si e trajton Rails. Nëse do të përdornit shtesën .json, do të dukej kështu:

Filloi GET "/posts.json" për 127.0.0.1 në 2013-12-04 12:02:01 -0800 Përpunimi nga PostsController # indeksi si JSON

Nëse keni një aplikacion testimi që funksionon, provoni të kërkoni URL të ndryshme. Nëse kontrolluesi juaj nuk di se si t'i trajtojë ato, atëherë mund të merrni një gabim, por duhet të shihni se çfarë kupton Rails nga kërkesat tuaja.

Rendering JSON ose XML

Kur vendosni që dëshironi t'u përgjigjeni kërkesave me JSON ose XML, duhet t'i tregoni kontrolluesit që të japë JSON ose XML në vend të HTML. Një mënyrë për ta bërë këtë është të përdorni metodën #reagoj_to:

Kontrolluesi i Përdoruesve të klasës< 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

Në këtë rast, #respond_to i kalon bllokut një objekt formati, të cilit mund t'i bashkëngjitni një thirrje të përshtatshme render. Nëse nuk bëni asgjë, html do të jepet duke përdorur shabllonin standard të Rails (app / views / index.html.erb në këtë shembull).

Veçoria #render është mjaft e zgjuar për të kuptuar se si të jepni një shumëllojshmëri të gjerë formatesh. Kur ia kaloni çelësin: json, ai do të thërrasë #to_json në vlerë, në këtë shembull @users. Kjo do t'i konvertojë objektet tuaja Ruby në vargjet JSON, të cilat do t'i kalojnë aplikacionit kërkues.

Në këtë mënyrë ju merrni API-në tuaj. Sigurisht, krijimi i një API mund të jetë pak më kompleks nëse doni të bëni disa gjëra të pazakonta, por gjithçka mbahet në bazat.

Specifikimi i atributeve të kthimit

Le të themi se dëshironi të siguroheni që të mos ktheni adresën e emailit të përdoruesit së bashku me objektin Përdorues. Në këtë rast, ju do të dëshironi të ndryshoni atributet që do të kthehen, duke modifikuar atë që bën metoda #to_json.

Më parë, thjesht do të anashkalonit metodën #to_json me versionin tuaj, por tani nuk ju nevojitet kjo - në fakt, në vend të kësaj do të anashkaloni metodën #as_json. Metoda #as_json përdoret në metodën #to_json, kështu që modifikimi i saj ndryshon në mënyrë implicite rezultatin #to_json, por në një mënyrë mjaft specifike.

#to_json bën 2 gjëra: ekzekuton #as_json dhe merr një hash atributesh që do t'i jepen JSON. Më pas ai jepet në JSON duke përdorur ActiveSupport :: json.encode. Pra, duke modifikuar #as_json, ju jeni më specifik për pjesën e metodës #to_json që dëshironi të ndryshoni.

Në rastin tonë, ne e bëjmë këtë duke modifikuar #as_json në modelin tonë për të kthyer vetëm atributet që na duhen:

# app / models / user.rb class Përdoruesi< ActiveRecord::Base # Вариант 1: Полное переопределение метода #as_json def as_json(options={}) { :name =>vetë.emri) # MOS përfshini fundin e fushës së emailit # Opsioni 2: Përdorni metodën standarde #as_json def as_json (opcione = ()) super (vetëm: [: emri]) fundi i fundit

Më pas, në kontrolluesin tonë, ne vetëm duhet të japim JSON si zakonisht (në shembullin më poshtë, JSON do të kthehet gjithmonë, pavarësisht nëse një kërkesë HTML është dërguar apo jo):

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

Vini re se nuk keni nevojë të telefononi vetë #to_json kur përdorni #render - ai e bën atë për ju.

Ndonjëherë Heroku mund të kërkojë hapa shtesë për të shfaqur saktë faqet tuaja të gabimit. Hidhi nje sy. Mund t'ju duhet fillimisht të hiqni faqet statike nga aplikacioni / drejtoria publike.

Siguria nga jashtë

Le të themi se dëshironi të lejoni qasjen në API vetëm nëse përdoruesi është i identifikuar. Autentifikimi juaj ekzistues në kontrollues tashmë e kryen punën - thjesht sigurohuni që të keni grupin e duhur #para_action (si para_aksioni: Kërko_login). Ju mund të keni nevojë për funksionalitet kur përdoruesit e regjistruar dhe jo të regjistruar mund ta shikojnë faqen, por të gjithë duhet të shohin të dhëna të ndryshme. Ju nuk dëshironi që përdoruesit e paloguar të jenë në gjendje të bëjnë kërkesa API për të marrë të dhëna të ndjeshme. Po kështu, ju nuk dëshironi të lejoni përdoruesit e paautorizuar të vizitojnë faqe të caktuara HTML.

Nëse dëshironi të përpunoni kërkesat nga një aplikacion jo shfletues (si p.sh. linja e komandës), nuk mund të mbështeteni te skedarët e skedarëve të shfletuesit për vërtetim. Kjo është arsyeja pse shumica e API-ve përdorin argumentet e tyre si pjesë e procesit të vërtetimit. Ne do të flasim pak më shumë për argumentet në tutorialin e ardhshëm.

Hapat e ardhshëm

Tani keni aftësitë për të përdorur aplikacionin tuaj Rails për të shërbyer jo vetëm HTML, por çdo format tjetër. Nëse dëshironi të shkoni më tej dhe të lejoni zhvilluesit e tjerë të ndërtojnë diçka duke përdorur platformën tuaj (për shembull, në mënyrë që ata të mund të bëjnë kërkesa programore në vend që të vërtetohen si përdorues), do t'ju duhet ta bëni sistemin tuaj API shumë më të sigurt. Ne nuk do t'i mbulojmë të gjitha këto këtu, por shikoni burimet e mëposhtme:

• Artikulli i Building Awesome Rails API përshkruan shumë nga qasjet më të mira për të lëvizur nga një aplikacion lodrash drejt standardeve industriale të API.

Arkitektura e orientuar drejt shërbimit

Është koha për të prezantuar një qasje arkitekturore të quajtur Arkitektura e Orientuar në Shërbimin (SOA). Ideja bazë është që aplikacioni juaj do të përbëhet nga shumë shërbime si sistemi i pagesave, regjistrimi i përdoruesit, moduli i rekomandimeve, etj. Në vend që të ndërtoni të gjitha këto brenda një aplikacioni kryesor, ju i ndani nënsistemet në pjesë krejtësisht të pavarura që ndërveprojnë me njëra-tjetrën duke përdorur API-të e brendshme.

Kjo është e mirë për shumë arsye. Meqenëse çdo pjesë e aplikacionit tuaj nuk i intereson sesi funksionojnë pjesët e tjera dhe di vetëm se si të kërkojë të dhëna përmes API-së së tyre, mund të bëni ndryshime të rëndësishme në kodin e shërbimit dhe pjesa tjetër e aplikacionit do të funksionojë si më parë. Ju mund të zëvendësoni plotësisht një shërbim me një tjetër, dhe për sa kohë që ai ndërvepron duke përdorur të njëjtat metoda API, do të shkojë shumë mirë. Ju mund të përdorni API-të e jashtme si pjesë e aplikacionit tuaj (si sistemet e pagesave) në vend që të shkruani tuajat. Ju mund të krijoni një aplikacion PHP që ndërvepron me një aplikacion Python që ndërvepron me një aplikacion Rails dhe gjithçka do të funksionojë, sepse ata komunikojnë me njëri-tjetrin duke përdorur API.

Në përgjithësi është një ide e mirë të përpiqeni të bëni çdo pjesë të aplikacionit tuaj sa më të pavarur që të jetë e mundur. Koncepti i SOA ju inkurajon të mendoni saktësisht se cilat metoda dëshironi t'i ekspozoni pjesëve të tjera të aplikacionit tuaj, dhe gjithashtu e bën kodin tuaj më të mirë. Përveç kësaj, duke supozuar se çdo komponent kryesor i aplikacionit tuaj është i pavarur, ju gjithashtu mund t'i izoloni problemet shumë më lehtë dhe t'i trajtoni gabimet në një mënyrë më kuptimplote.

Përdorimi i një arkitekture të orientuar nga shërbimi për një aplikacion të tërë është si zbërthimi i një skripti gjigant, kompleks Ruby në klasa dhe metoda të shkëlqyera, vetëm në një shkallë më të madhe.

Një nga rastet më të njohura të kalimit në një arkitekturë të orientuar drejt shërbimit është Amazon.com. Një ditë në 2002, Jeff Bezos tha troç se të gjitha grupet e punës duhet të shkojnë në SOA, ose të pushohen nga puna. Famëkeq postim në blog një punonjës i Google, i destinuar për qëllime të brendshme, por i bërë aksidentalisht publik, foli për fuqinë e Amazon duke përdorur SOA. Ky është lexim i shkëlqyer, ndaj sigurohuni ta vlerësoni, por tezat kryesore të letrës së Bezos janë bërë në citimet e mëposhtme nga postimi:

1) Të gjitha ekipet tani e tutje ofrojnë të dhënat dhe funksionalitetin e tyre përmes ndërfaqeve të shërbimit.

2) Ekipet duhet të komunikojnë me njëri-tjetrin përmes këtyre ndërfaqeve.

3) Format e tjera të komunikimit ndërprocesor janë të ndaluara: pa lidhje direkte, pa lexim të drejtpërdrejtë të të dhënave të një komande tjetër, pa modele memorie të përbashkëta, pa dyer të pasme dhe të ngjashme. Mënyra e vetme e lejuar e komunikimit është qasja në ndërfaqen e shërbimeve përmes rrjetit.

4) Nuk ka rëndësi se çfarë teknologjie përdorin. HTTP, Corba, Pubsub, protokollet e pronarit - nuk ka dallim. Bezos nuk i intereson.

5) Të gjitha ndërfaqet e shërbimit, pa përjashtim, duhet të jenë të dizajnuara fillimisht me aftësinë për të kontrolluar nga jashtë. Kjo do të thotë, ekipi duhet të planifikojë dhe dizajnojë që të jetë në gjendje të sigurojë një ndërfaqe për zhvilluesit jashtë kompanisë. Nuk ka përjashtime.

6) Kushdo që ka injoruar këto kërkesa do të shkarkohet.

SOA është një biznes serioz. Ka padyshim shumë probleme që shfaqen kur e përdorni - shikoni këtë postim në "mësimet e nxjerra" në Amazon - por ka një numër të jashtëzakonshëm përfitimesh.

Ndoshta nuk do të shqetësoheni shumë për SOA-në ndërkohë që krijoni aplikacione "lodër" për veten tuaj, por kjo pyetje do të lindë patjetër kur të filloni të punoni për një kompani IT, ndaj njohja me të është një praktikë e mirë.

Qëllimi juaj

1. Lexoni seksionin 7 të Udhëzuesit të Rails për Kontrollorët për të mësuar rreth paraqitjes së JSON dhe XML.
2. Ato janë opsionale (sepse shkojnë pak më larg se sa kemi aktualisht), por nëse jeni të interesuar, hidhini një sy Railscasts në seksionin Burime shtesë në fund të tutorialit për të mësuar më shumë rreth përfitimeve të API-së.

konkluzioni

Ne do të punojmë më ngushtë me aplikacionin tuaj si një API gjatë kursit Javascript. Në këtë kurs, ju do të krijoni disa aplikacione të plota që përdorin thirrje AJAX për një ndërfaqe më të mirë të përdoruesit, e cila në fakt përfshin paraqitjen e të dhënave XML ose JSON në vend të një faqeje të plotë HTML. Më pas, do të krijoni disa aplikacione Javascript me një faqe që mbështeten në API-në e ofruar nga aplikacioni juaj Rails për të marrë të gjitha të dhënat që i nevojiten nga baza e të dhënave dhe përndryshe të ekzekutohen në anën e klientit (në shfletues).

Mënyra më e mirë për të kuptuar API-në është krijimi dhe ndërveprimi me të, në të cilin do të fokusohemi në projektet tona.

Në këtë postim, u përpoqa të mbledh informacione që mund të jenë të dobishme për testuesit që duan të dinë se çfarë është një API. Shpresoj se njerëzit që kanë përvojë në testimin e API do të gjejnë diçka të dobishme për veten e tyre. Epo, ose të paktën t'ju ndihmoj të gjeni gabime në artikullin tim :)
Çfarë është API

API (Application Programming Interface) është një grup klasash, procedurash, funksionesh, strukturash dhe konstantesh të gatshme të ofruara nga një aplikacion (bibliotekë, shërbim) për përdorim në produkte të jashtme softuerike (Wikipedia).

Me fjalët tona, API na ofron mundësinë për të përdorur punën e njerëzve të tjerë për qëllimet tona. Fillimisht u ndesha me API-në duke përdorur API-në e Windows si shembull. Ky është një grup funksionesh që mund të përdoren nga çdo aplikacion që funksionon në një OS të caktuar. Për shembull, mund të përdorë funksione standarde për të paraqitur ndërfaqen.

API-të moderne shpesh marrin formën e shërbimeve të internetit që ofrojnë informacion për përdoruesit (si njerëzit ashtu edhe shërbimet e tjera të internetit). Zakonisht, procedura e shkëmbimit të informacionit dhe formati i transferimit të të dhënave janë të strukturuara në mënyrë që të dyja palët të dinë se si të ndërveprojnë me njëra-tjetrën.

Në faqen https://dev.hh.ru/ (më saktë, https://github.com/hhru/api/blob/master/docs/general.md) mund të gjeni një përshkrim se si klientët API të HeadHunter dhe shërbimet ndërveprojnë me njëri-tjetrin. Për shembull, një citat nga faqja:

• I gjithë API funksionon mbi protokollin HTTPS.
• Autorizimi kryhet duke përdorur protokollin OAuth2.
• Të gjitha të dhënat disponohen vetëm në formatin JSON.
• URL-ja bazë - https://api.hh.ru/
• Datat janë të formatuara sipas ISO 8601: YYYY-MM-DDThh: mm: ss ± hhmm

Ju mund të lexoni HH API për një shembull të mirë të dokumentacionit të personalizuar.

Formatet e transferimit të të dhënave

Ka shumë formate të dhënash që përdoruesit përdorin për të bashkëvepruar me API-në. Për shembull, XML e njohur. Ose JSON është një format i lehtë dhe i pakomplikuar që duket si:

("id": "0001", "lloji": "donut", "emri": "tortë", "imazh": ("url": "imazhe / 0001.jpg", "gjerësia": 200, "lartësia" ": 200)) P o ss Lidhjet më poshtë mund të shihni përgjigjet që vijnë nga MediaWikiAPI , në formate të ndryshme :

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 ( me kujdes, do të ndodhë me lëkundje skedar)

Http r lagolët

Zakonisht P Kur hyni në web APIduke përdorur ka kërkesa HTTP . Kështu qëMë duhet të them të paktën shkurtimisht metoda standarde, të cilat mund të përmbahen në Kërkesë HTTP . Këto metoda quhen edhe folje HTTP :

• MARR. Ndoshta lloji më i popullarizuar kërkesë. Përdoret për të marrë ose lexuar të dhëna.
• VENDOSJE. Me porosi n oh dhe spo përdoret për të përditësuar burimin .
• POST. Zakonisht përdoret për të krijuar një burim të ri.
• FSHIJE. Fshin të dhënat.
• Të tjera

Nëse duam të marrim informacion për një burim,URI e kujt http://www.example.com/customers/12345 , ne mund të dërgojmë një kërkesë:
MERRNI http://www.example.com/customers/12345

Nëse duam të përditësojmë një burim - ne mund të dërgojmë një kërkesë PUT:
VENDOS http://www.example.com/customers/12345/orders/98765

Kërkesat e rregullta GET mund të dërgohen nga shfletuesi i internetit. Për të dërguar lloje të tjera kërkesash, mund të kërkohen gjuhë skriptimi ose mjete speciale (më shumë për këtë më poshtë).

Rreth HTTP metodat mund të lexohen më në detaje në në W iki.

HTTP tek odat e përgjigjeve

Serveri mund të dërgojë kode të ndryshme në përgjigje të kërkesave të përdoruesve. Këto mund të jenë kode gabimi ose thjesht kode që informojnë përdoruesit për gjendjen e serverit. Një përshkrim i detajuar mund të gjendet përsëri në wiki.

Kodet më të famshme janë 4xx (probleme nga ana e klientit) dhe 5xx (probleme nga ana e serverit). Vetë zhvilluesit e API vendosin se cilat kode të kthehen në një situatë të caktuar. Për shembull, API e faqes së internetit Odnoklassniki kthen kode, përshkrimi i të cilave mund të gjendet në https://apiok.ru/wiki/pages/viewpage.action?pageId=77824003.

Për më tepër, unë ju këshilloj të dëgjoni këngën Request Response - është e thjeshtë dhe e qartë për kodet e kthyera në kërkesat HTTP (kini kujdes, repchik :)).

REST API

REST API është ideologjia e postimit gëlltitje API, e cila qëndron përTransferimi i shtetit përfaqësues API. Ai bazohet në parimet e mëposhtme të formuluara nga krijuesi i tij Nga Roy Fielding:

1. Arkitektura klient-server
2. Server pa shtetësi
3. Cacheability
4. Struktura me shumë shtresa
5. Ndërfaqe e unifikuar
6. Kodi sipas kërkesës

Nuk do të hyj në detaje, mund t'i këshilloj ata që duan të lexojnë mbi temën