Přenos dat API. Co je API

Pravděpodobně jste viděli termín "API". Aktualizace operačního systému, webového prohlížeče a aplikací často oznamují nová rozhraní API pro vývojáře. Ale co je API?

Aplikační programovací rozhraní

Termín API je zkratka a znamená „Application Programming Interface“.

API je jako jídelní lístek v restauraci. Jídelní lístek obsahuje seznam jídel, která si můžete objednat, a také popis každého jídla. Když určíte, které položky menu chcete, kuchyně restaurace to udělá a poskytne vám hotová jídla. Nevíte přesně, jak restaurace toto jídlo připravuje a ani to nepotřebujete.

Stejně tak API poskytuje mnoho operací, které mohou vývojáři použít, a také popis toho, co dělají. Vývojář nemusí vědět, jak se například vytvoří operační systém a zobrazí se dialogové okno Uložit jako. Potřebují jen vědět, že je k dispozici pro použití v aplikaci.

Není to dokonalá metafora, protože vývojáři možná budou muset poskytnout svá vlastní data API, aby dosáhli výsledků, takže možná je to spíše jako luxusní restaurace, kde můžete poskytnout nějaké své vlastní ingredience, se kterými bude kuchyně pracovat.

Rozhraní API umožňují vývojářům ušetřit čas tím, že využijí vkládání platformy k provedení důležité práce. To pomáhá snížit množství kódu, který vyvíjíte, a také pomáhá vytvářet konzistenci mezi aplikacemi na stejné platformě. Rozhraní API mohou řídit přístup k hardwarovým a softwarovým prostředkům.

Rozhraní API usnadňují vývojářům život

Řekněme, že chcete vyvinout aplikaci pro iPhone. Operační systém Apple iOS poskytuje velké množství rozhraní API, stejně jako jakýkoli jiný operační systém, aby vám to usnadnil.

Chcete-li například vložit webový prohlížeč pro zobrazení jedné nebo více webových stránek, nemusíte od začátku kódovat svůj vlastní webový prohlížeč pouze pro vaši aplikaci. Vy
Pomocí rozhraní WKWebView API můžete do své aplikace vložit webový prohlížeč WebKit (Safari).

Pokud chcete pořizovat fotografie nebo videa z fotoaparátu iPhonu, nemusíte si psát vlastní rozhraní fotoaparátu. K vložení fotoaparátu iPhone do aplikace můžete použít rozhraní Camera API. Pokud by API neexistovalo, museli by vývojáři aplikací napsat svůj vlastní software fotoaparátu a interpretovat hardwarové vstupy fotoaparátu. Vývojáři operačního systému Apple ale udělali všechnu tvrdou práci, takže vývojáři mohou jednoduše použít rozhraní API fotoaparátu k vložení fotoaparátu a poté pokračovat v psaní své aplikace. A když Apple vylepší rozhraní API fotoaparátu, všechny aplikace, které jej používají, toto vylepšení automaticky využijí.

To platí pro všechny platformy. Chcete například vytvořit dialogové okno ve Windows? Existuje na to API. Chcete podporovat ověřování otisků prstů na Androidu? Existuje na to API, takže nemusíte testovat každý snímač otisků prstů od každého výrobce Androidu. Vývojáři nemusí znovu a znovu vynalézat kolo.

Rozhraní API řídí přístup ke zdrojům

Rozhraní API se také používají k řízení přístupu k hardwarovým zařízením a softwarovým funkcím, k jejichž použití aplikace nemusí mít oprávnění. To je důvod, proč API často hrají velkou roli v zabezpečení.

Pokud jste například někdy navštívili webovou stránku a v prohlížeči se vám zobrazila zpráva, že webová stránka požaduje vaši přesnou polohu, tato webová stránka se pokouší použít geolokační API ve vašem webovém prohlížeči. Webové prohlížeče poskytují rozhraní API, která usnadňují webovým vývojářům přístup k vaší poloze – mohou se jednoduše zeptat „kde jste?“ a prohlížeč odvede těžkou práci při přístupu k GPS nebo blízkým Wi-Fi sítím, aby zjistil vaši fyzickou polohu.

Prohlížeče však tyto informace poskytují také prostřednictvím API, protože přístup k nim lze řídit. Když chce webová stránka získat přístup k vaší přesné poloze, jediný způsob, jak ji získat, je prostřednictvím rozhraní Location API. A když se to webová stránka pokusí použít, vy – uživatel – můžete žádost povolit nebo zamítnout. Přístup k hardwarovým prostředkům, jako je senzor GPS, je možný pouze prostřednictvím API, takže prohlížeč může řídit přístup k hardwaru a omezovat aplikace.

Stejný princip se používá pro moderní mobilní operační systémy, jako je iOS a Android, kde mobilní aplikace mají oprávnění, která lze implementovat pomocí řízení přístupu API. Pokud se například vývojář pokusí získat přístup ke kameře prostřednictvím rozhraní API fotoaparátu, můžete žádost o povolení zamítnout a aplikace nebude mít přístup ke kameře vašeho zařízení.

Systémy souborů, které používají oprávnění, stejně jako v systémech Windows, Mac a Linux, mají stejná oprávnění, která jsou aplikována rozhraním API systému souborů. Typická aplikace nemá přímý přístup k surovému fyzickému pevnému disku. Místo toho musí aplikace přistupovat k souborům prostřednictvím rozhraní API.

API se používají ke komunikaci mezi službami

API se používají i z jiných důvodů. Pokud jste například někdy viděli objekt Map Google vložený do webové stránky, tato webová stránka používá k vložení této mapy rozhraní Google Maps API. Google poskytuje podobná rozhraní API pro webové vývojáře, kteří pak mohou tato rozhraní použít k sestavování složitých objektů přímo na svých webových stránkách. Pokud taková rozhraní API neexistují, vývojáři možná budou muset vytvořit své vlastní mapy a poskytnout svá vlastní mapová data, aby mohli hostovat malou interaktivní mapu na webové stránce.

A protože se jedná o API, Google může řídit přístup k Mapám Google na webech třetích stran a zajistit, aby je používali konzistentním způsobem, místo aby se pokoušeli náhodně vložit rámec, který zobrazuje například web Map Google.

To platí pro mnoho různých online služeb. Existují rozhraní API pro vyžádání překladu textu z Překladače Google nebo zobrazení komentářů na Facebooku nebo tweetů z Twitteru na webových stránkách.

Standard OAuth také definuje řadu rozhraní API, která vám umožňují přihlásit se k webu prostřednictvím jiné služby, jako je použití účtů Facebook, Google nebo Twitter k přihlášení na nový web bez vytvoření nového uživatelského účtu pouze pro daný web. . API jsou standardní smlouvy, které definují, jak vývojáři interagují se službou a druh produktu, který by vývojáři měli očekávat.

Pokud jste si přečetli tento článek, budete lépe rozumět tomu, co je API. Nakonec nemusíte vědět, co je API, pokud nejste vývojář. Pokud však zjistíte, že softwarová platforma nebo služba přidala nová rozhraní API pro jiný hardware nebo služby, mělo by být pro vývojáře jednodušší takové funkce používat.

Windows API – sada funkcí operačního systému

Zkratka API se mnohým začínajícím programátorům zdá velmi tajemná až děsivá. Ve skutečnosti je aplikační programovací rozhraní (API) jen nějaká hotová sada funkcí, které mohou vývojáři aplikací používat. Obecně je tento koncept ekvivalentní tomu, co se dříve častěji nazývalo knihovna podprogramů. API je však obvykle chápáno jako zvláštní kategorie takových knihoven.

Při vývoji téměř jakékoli poměrně složité aplikace (MyApplication) se pro koncového uživatele vytváří sada specifických interních funkcí, pomocí kterých je implementován tento konkrétní program, který se nazývá MyApplication API. Často se však ukazuje, že tyto funkce lze efektivně využít k tvorbě dalších aplikací, včetně jiných programátorů. V tomto případě se autoři na základě strategie propagace svého produktu musí rozhodnout, zda otevřou přístup k této sadě pro externí uživatele či nikoliv? Pokud je odpověď ano, v popisu softwarového balíčku se jako pozitivní charakteristika objeví věta: „Balík obsahuje otevřenou sadu funkcí API“ (ale někdy za další peníze).

API tedy nejčastěji označuje sadu funkcí, které jsou součástí jedné aplikace, ale zároveň jsou dostupné pro použití v jiných programech. Například Excel má kromě rozhraní pro koncového uživatele sadu funkcí Excel API, které lze využít zejména při vytváření aplikací pomocí VB.

V souladu s tím je Windows API souborem funkcí, které jsou součástí samotného operačního systému a zároveň jsou dostupné jakékoli jiné aplikaci, včetně těch napsaných pomocí VB. V tomto ohledu je analogie se sadou přerušení systému BIOS/DOS, což je vlastně DOS API, celkem oprávněná.

Rozdíl spočívá v tom, že skladba funkcí Windows API je na jedné straně mnohem širší ve srovnání s DOSem, na druhé straně neobsahuje mnoho nástrojů pro přímou správu počítačových zdrojů, které byly k dispozici programátory v předchozím OS. Přístup k Windows API je navíc prováděn pomocí běžných procedurálních volání a funkce DOSu jsou volány prostřednictvím speciální strojové instrukce procesoru, která se nazývá Interrupt ("přerušení").

Proč potřebujete Win API pro programátory VB

Navzdory skutečnosti, že VB má obrovskou škálu funkcí, v procesu více či méně seriózního vývoje se ukazuje, že jejich schopnosti často nestačí k vyřešení nezbytných úkolů. Zároveň si začínající programátoři často začínají stěžovat na nedostatky VB a přemýšlejí o změně nástrojů, aniž by tušili, že jejich počítač má obrovskou sadu nástrojů a stačí vědět, jak je používat.

Při seznamování s Win API se ukazuje, že mnoho vestavěných funkcí VB není nic jiného než volání odpovídajících systémových procedur, ale pouze implementovaných ve formě syntaxe tohoto jazyka. S ohledem na to je potřeba použít rozhraní API určena následujícími možnostmi:

1. Funkce API, které jsou plně implementovány jako vestavěné funkce VB. Někdy je však v tomto případě užitečné přejít na použití API, protože to může někdy výrazně zlepšit výkon (zejména kvůli absenci zbytečných konverzí předávaných parametrů).
2. Vestavěné funkce VB implementují pouze speciální případ odpovídající funkce API. Toto je poměrně častá možnost. Například rozhraní CreateDirectory API je výkonnější než vestavěný příkaz VB MkDir.
3. Obrovské množství funkcí API nemá v současné verzi jazyka VB vůbec obdoby. Nemůžete například smazat adresář pomocí VB – k tomu musíte použít funkci DeleteDirectory.

Je třeba také zdůraznit, že některé funkce API (jejich podíl na Win API je velmi malý) nelze volat z programů VB z důvodu řady jazykových omezení, například z důvodu chybějící možnosti práce s adresami paměti. V některých případech však mohou pomoci netriviální programovací techniky (zejména v případě stejných adres).

Osobní názor autora je takový, že namísto rozšiřování z verze na verzi vestavěných funkcí VB by měl člověk podat dobrý popis nejoblíbenějších funkcí API. Zároveň bych chtěl vývojářům poradit, aby nečekali na novou verzi nástroje s pokročilými funkcemi, ale pečlivě prostudovali složení stávajícího Win API – je pravděpodobné, že funkce, které potřebujete, by mohly být implementovány již v verze VB 1.0 z roku 1991.

Jak se naučit Win API

To není tak jednoduchá otázka, vzhledem k tomu, že počet funkcí Win32 API se odhaduje kolem 10 000 (přesné číslo nikdo nezná, ani Microsoft).

VB (verze 4-6) obsahuje soubor s popisem deklarací Win API - WIN32API.TXT (o jeho použití více později). Ale za prvé jej lze použít k získání informací o účelu konkrétní funkce a jejích parametrech pouze podle použitých mnemotechnických názvů a za druhé, seznam funkcí v tomto souboru není zdaleka úplný. V jednu dobu (před sedmi lety) měl VB 3.0 speciální soubory nápovědy popisující funkce Win16 API. Již ve verzi 4.0 však tyto užitečné informace s pohodlným rozhraním zmizely.

Úplné informace o Win32 API lze nalézt v nápovědě Platform Software Development Kit, která je obsažena na CD s knihovnou MSDN, která jsou součástí VB 5.0 a 6.0 Enterprise Edition a Office 2000 Developer Edition. Najít tam potřebné informace a porozumět jim však není jednoduché. Nemluvě o tom, že všechny popisy tam jsou uvedeny ve vztahu k jazyku C.

Světově uznávaným průvodcem pro výuku programování API v prostředí VB jsou knihy slavného amerického odborníka Daniela Applemana. Jeho série Dan Appleman's Visual Basic Programmer's Guide to Windows API (pro Win16, Win32, ve vztahu k různým verzím VB) je od roku 1993 trvale bestsellerem pro programátory VB. VB 5.0 Programmer's Guide to the Win32 API od Dana Applemana, vydaný v roce 1997, přinesl autorovi z USA kamarád, který ho našel v prvním knihkupectví v malém provinčním městě.

Tato kniha má více než 1 500 stran a zahrnuje obecné programovací techniky VB API a také více než 900 funkcí. Doprovodný CD-ROM obsahuje plný text knihy a všechny příklady programování a také několik dalších kapitol, které nejsou součástí tištěné verze. V roce 1999 vydal Dan Appleman novou knihu Dan Appleman's Win32 API Puzzle Book and Tutorial for Visual Basic Programmers, která obsahuje informace o dalších 7600 funkcích (ačkoli ne tak rozsáhlé).

Win API a dynamická knihovna (DLL)

Sada Win API je implementována jako dynamické knihovny DLL. Dále si vlastně povíme o technologii použití DLL v prostředí VB na příkladu knihoven, které jsou součástí Win API. Když však mluvíme o knihovnách DLL, je třeba si uvědomit několik důležitých věcí.

DLL v tomto případě rozumíme tradiční variantu binárních dynamických knihoven, které poskytují aplikacím přímý přístup k potřebným procedurám - podprogramům nebo funkcím (podobně jako se to děje při volání procedur uvnitř VB projektu). Takové knihovny lze vytvářet pomocí různých nástrojů: VC ++, Delphi, Fortran, kromě VB (uvidíme, co se objeví ve verzi 7.0) - ta umí vytvářet pouze ActiveX DLL, ke kterým se přistupuje přes rozhraní OLE Automation.

Soubory dynamicky propojované knihovny mají obvykle příponu .DLL, ale to není vůbec nutné (pro Win16 se často používala přípona .EXE); Ovladače externích zařízení jsou označeny .DRV.

Jak jsme již poznamenali, je poměrně obtížné určit přesný počet Windows API a souborů, které je obsahují, ale všechna jsou umístěna v systémovém adresáři. V tomto ohledu je lepší vyzdvihnout složení knihoven obsažených v jádru operačního systému a hlavních knihoven s klíčovými doplňkovými funkcemi.

A teď pár tipů.

Tip 1: Ujistěte se, že je vaše reklama DL správně naformátována L-procedury

Samotné volání procedur DLL v programu vypadá úplně stejně jako „běžné“ procedury jazyka Visual Basic, například:

Volání DllName([seznam argumentů])

Chcete-li však používat externí funkce DLL (včetně rozhraní Win API), musí být deklarovány v programu pomocí příkazu Declare, který vypadá takto:

Deklarujte Sub LibProcedureName _ “LibraryName” _ [([ArgumentList])]

Deklarujte funkci FunctionName _ Lib "LibraryName" _ [([ArgumentList])]

Zde jsou volitelné prvky operátoru uvedeny v hranatých závorkách, proměnné výrazu jsou kurzívou, zbytek slov jsou klíčová slova. Systém nápovědy má docela dobrý popis syntaxe operátoru, takže zatím jen pár bodů.

Externí deklarace funkcí musí být umístěny v sekci Obecné deklarace modulu. Pokud jej umístíte do modulu formuláře, musíte zadat klíčové slovo Private (tato deklarace bude k dispozici pouze uvnitř tohoto modulu) - to je omezení pro všechny procedury modulu formuláře.

Sada Win32 API je implementována pouze jako funkce (Win16 API mělo mnoho Sub rutin). Z velké části se jedná o funkce typu Long, které nejčastěji vracejí kód dokončení operace.

Příkaz Declare se objevil v MS Basic ještě v dobách DOSu a sloužil také k deklaraci interních postupů projektu. V jazyce Visual Basic to není vyžadováno, protože deklarace interních procedur je automaticky jejich deklarací Sub nebo Function. Oproti Basic/DOS je v novém popisu povinné uvést jméno souboru knihovny, kde se nachází požadovaná procedura. Knihovny Wip API jsou umístěny v systémovém adresáři Windows, takže stačí uvést pouze název souboru. Pokud přistupujete ke knihovně DLL, která se nachází v libovolném umístění, musíte si zapsat úplnou cestu k tomuto souboru.

Popis příkazu Declare obvykle zabírá poměrně hodně místa a nevejde se na jeden řádek v okně kódu. Proto doporučujeme, abyste se při psaní aplikací řídili konkrétním schématem zalamování řádků, například:

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

V tomto případě jsou všechny hlavní prvky popisu rozděleny do různých řádků, a proto jsou dobře čitelné.

Tip 2: Buďte obzvláště opatrní při práci s funkcemi DLL

Použití Win API a různých funkcí DLL výrazně rozšiřuje funkčnost VB a často zlepšuje výkon programů. Odplatou za to je však riziko snížení spolehlivosti aplikace, zejména v procesu jejího ladění.

Jednou z nejdůležitějších výhod prostředí VB je spolehlivost procesu programování: fungující pod kontrolou interpretu nemůže programový kód teoreticky narušit chod Windows a samotného VB. Programátor nemusí dávat velký pozor na správnost předávání parametrů volaným funkcím - takové chyby snadno odhalí samotný interpret buď v procesu překladu kódu nebo během jeho provádění. V nejnepříjemnějším případě bude režim zpracování jednoduše přerušen as uvedením, kde a proč došlo k chybě.

Přímé použití funkcí Windows API nebo jiných knihoven DLL odstraňuje takovou kontrolu nad přenosem dat a spouštěním kódu mimo prostředí VB. Chyba v přístupu k externím funkcím tedy může vést k nefunkčnosti VB i operačního systému. To platí zejména ve fázi vývoje programu, kdy je přítomnost chyb zcela přirozená. Aplikací širších možností funkcí základní vrstvy systému tedy programátor přebírá odpovědnost za správnost jejich aplikace.

Problém je umocněn skutečností, že různé programovací jazyky používají různé způsoby předávání parametrů mezi procedurami. (Přesněji řečeno, ve výchozím nastavení se používají různé metody předávání, protože mnoho jazyků může podporovat více metod.) Rozhraní Win API jsou implementována v C/C++ a používají konvence předávání parametrů C/C++, které se liší od toho, k čemu se používá VB .

V tomto ohledu je třeba poznamenat, že výskyt analogů funkcí API zabudovaných do VB je odůvodněn právě přizpůsobením těchto funkcí syntaxi VB a implementací odpovídajícího mechanismu řízení výměny dat. Všimněte si také, že ve fázi experimentálního ladění aplikace, při vytváření spustitelného modulu, je lepší použít možnost kompilace P-kódu místo Native Code (strojový kód). V prvním případě poběží program pod kontrolou tlumočníka – pomaleji než strojový kód, ale spolehlivější z hlediska možných chybných vlivů na operační systém a poskytuje pohodlnější režim pro detekci případných chyb.

Tip 3: Deset tipů Dana Applemana pro spolehlivé programování API ve VB

Použití funkce API vyžaduje pečlivější programování pomocí některých neznámějších metod volání procedur (ve srovnání s VB). Těmto problémům se budeme dále věnovat. A nyní je zde shrnutí rad Dana Applemana na toto téma (jejich první verze se objevila již v roce 1993), s některými našimi dodatky a komentáři.

1. Pamatujte na ByVal. Nejčastější chybou při přístupu k funkcím API a DLL je nesprávné použití klíčového slova ByVal: buď ho zapomenou nastavit, nebo naopak nastaví, když není potřeba.

Tyto příklady ukazují vliv příkazu ByVal na předávání parametrů

Zde je třeba připomenout, že přenos parametrů v jakémkoli programovacím systému, včetně VB, se provádí dvěma hlavními způsoby: odkazem (ByRef) nebo hodnotou (ByVal). V prvním případě je předána adresa proměnné (tato možnost se ve VB standardně používá), ve druhém - její hodnota. Zásadní rozdíl spočívá v tom, že pomocí reference je volajícímu programu vrácena změněná hodnota předávaného parametru.

Abyste tomu porozuměli, proveďte experiment pomocí následujících programů:

Dim v As Integer v = 2 Volání MyProc(v) MsgBox “v = “ & v Sub MyProc (v As Integer) v = v + 1 End Sub

Při spuštění tohoto příkladu obdržíte zprávu s hodnotou proměnné rovnou 3. Faktem je, že v tomto případě je adresa proměnné v, fyzicky vytvořená ve volajícím programu, předána podprogramu MyProc. Nyní změňte popis postupu na

Sub MyProc (ByVal v. As Integer)

Ve výsledku při spuštění testu dostanete v = 2, protože do procedury je předána pouze počáteční hodnota proměnné – výsledek operací na ní provedených se nevrací volajícímu programu. Režim předání můžete změnit také pomocí příkazu Call následovně:

Sub MyProc (v As Integer) ... Call MyProc((v)) ‘ (v) - závorky označují režim pass-by-value _.

Při odkazu na interní procedury VB je však použití klíčového slova ByVal v příkazu Call zakázáno – místo toho jsou použity závorky. To má své vlastní vysvětlení.

V klasickém případě (C, Fortran, Pascal) závisí rozdíl mezi režimy ByRef a ByVal na tom, co přesně je umístěno na zásobníku výměny dat - adresa proměnné nebo její hodnota. Basic historicky používá variantu softwarové emulace ByVal - adresa je vždy na zásobníku, ale pouze při průchodu hodnotou je k tomu vytvořena dočasná proměnná. Pro rozlišení mezi těmito dvěma možnostmi (klasická a základní) se používají různé způsoby popisu režimu ByVal. Všimněte si, že emulace režimu ByVal ve VB poskytuje vyšší spolehlivost programu: záměnou formy volání programátor riskuje pouze to, že se volajícímu programu vrátí (nebo nevrátí) opravená hodnota proměnné. V "klasické" verzi však taková záměna může vést k fatální chybě při provádění procedury (například když je místo adresy paměti použita proměnná rovna řekněme nule).

Funkce DLL jsou implementovány podle "klasických" principů, a proto vyžadují povinný popis způsobu výměny dat s každým z argumentů. K tomu slouží deklarace funkcí prostřednictvím popisu Declare (přesněji seznamu předávaných argumentů). Nejběžnějším způsobem předání parametrů funkci Windows API nebo DLL je použití klíčového slova ByVal. Navíc jej lze nastavit jak v příkazu Declare, tak přímo při volání funkce.

Důsledky nesprávného předávání parametrů lze snadno předvídat. Pokud obdržíte zjevně neplatnou adresu, obdržíte zprávu GPF (General Protection Fault). Pokud funkce obdrží hodnotu, která se shoduje s platnou adresou, pak funkce API proleze do oblasti někoho jiného (například do jádra Windows) se všemi z toho plynoucími katastrofálními následky.

2. Zkontrolujte typ předávaných parametrů. Neméně důležitý je správný počet a typ předávaných parametrů. Argumenty deklarované v Declare musí odpovídat očekávaným parametrům ve funkci API. Nejčastější případ chyby při předávání parametrů souvisí s rozdílem mezi hodnotou NULL a řetězcem nulové délky – nezapomeňte, že nejde o totéž.

3. Zkontrolujte typ návratu.

VB je docela tolerantní k neshodám typu návratu funkcí, protože číselné hodnoty se obvykle vracejí prostřednictvím registrů, nikoli zásobníku. Následující pravidla pomohou určit správnou hodnotu vrácenou funkcí API:

• Funkce DLL, která nevrací hodnotu (analogická jako void v 'C'), musí být deklarována jako VB Sub.
• funkce API, která vrací celočíselnou hodnotu (Integer nebo Long), může být definována jako Sub nebo Funkce, která vrací hodnotu odpovídajícího typu.
• žádná z funkcí API nevrací čísla s plovoucí desetinnou čárkou, ale některé knihovny DLL mohou vracet takový datový typ.

4. Konstrukci "Jakokoli" používejte s velkou opatrností. Mnoho funkcí Windows API má schopnost přijímat parametry různých typů a používat konstrukci As Any (interpretace typu se provádí v závislosti na hodnotě ostatních předávaných parametrů).

Dobrým řešením v tomto případě může být použití více aliasů funkcí (Alias) s vytvořením dvou nebo více deklarací pro stejnou funkci, přičemž každá z deklarací specifikuje parametry určitého typu.

5. Nezapomeňte inicializovat řetězce. V rozhraní Win API je mnoho funkcí, které vracejí informace načítáním dat do vyrovnávacích pamětí řetězců předávaných jako parametr. Zdá se, že ve vašem programu děláte vše správně: nezapomeňte na ByVal, správně předejte parametry funkci. Systém Windows však nemůže zkontrolovat, jak velká je velikost paměti přidělené pro řetězec. Řádek musí být dostatečně velký, aby pojal všechna data, která do něj lze umístit. Je odpovědností programátora VB, aby rezervoval vyrovnávací paměť správné velikosti.

Všimněte si, že na 32bitových Windows se řetězce převádějí z Unicode (dvoubajtové kódování) na ANSI (jednobajtové) a naopak, přičemž se berou v úvahu národní nastavení systému. Pro rezervaci vyrovnávacích pamětí je proto někdy vhodnější použít bajtové pole místo řetězcových proměnných. (Více o tom bude diskutováno níže.)

Funkce Win API vám častěji umožňují definovat maximální velikost bloku sami. Konkrétně to někdy vyžaduje volání další funkce API, která „vyzve“ velikost bloku. Například GetWindowTextLength umožňuje určit velikost řetězce potřebného pro umístění nadpisu okna vráceného funkcí GetWindowText. V tomto případě systém Windows zajistí, že nepřekročíte hranice.

6. Ujistěte se, že používáte Option Explicit.

7. Pečlivě zkontrolujte hodnoty parametrů a návratové hodnoty. VB má dobré možnosti kontroly typu. To znamená, že když se pokusíte předat funkci VB neplatný parametr, nejhorší věc, která se může stát, je, že dostanete od VB chybovou zprávu. Ale tento mechanismus bohužel nefunguje při přístupu k funkcím Windows API.

Windows 9x má vylepšený systém kontroly parametrů pro většinu funkcí API. Přítomnost chyby v datech tedy obvykle nezpůsobí fatální chybu, ale není tak snadné určit, co ji způsobilo.

Zde vám můžeme poradit, abyste použili několik způsobů ladění tohoto typu chyby:

• použijte ladění krok za krokem nebo příkaz Debug.Print ke kontrole každého podezřelého volání funkce API. Zkontrolujte výsledky těchto volání, abyste se ujistili, že je vše v pořádku a funkce řádně ukončena;
• použijte ladicí program Windows, jako je CodeView, a ladicí verzi Windows (poskytovanou v sadě Windows SDK). Tyto nástroje mohou detekovat chybu parametru a alespoň určit, která funkce API chybu způsobuje;
• používat další nástroje třetích stran ke kontrole typů parametrů a platnosti jejich hodnot. Takové nástroje umí nejen najít chyby parametrů, ale dokonce ukázat na řádek kódu VB, kde k chybě došlo.

Kromě toho je nutné zkontrolovat výsledek spuštění funkce API.

8. Pamatujte, že celá čísla ve VB a ve Windows nejsou totéž. Nejprve byste měli mít na paměti, že výraz „Integer“ ve VB označuje 16bitové číslo, v dokumentaci Win 32 - 32bitové číslo. Za druhé, celá čísla (Integer a Long) ve VB jsou hodnoty se znaménkem (to znamená, že jeden bit se používá jako znaménko, zbytek se používá jako mantisa čísla), ve Windows se používají pouze nezáporná čísla. Tuto okolnost je třeba mít na paměti, když vytváříte předávaný parametr pomocí aritmetických operací (například vypočítat adresu sečtením základu a offsetu). Standardní aritmetické funkce VB k tomu nejsou vhodné. Jak být v tomto případě, budeme mluvit samostatně.

9. Věnujte zvýšenou pozornost názvům funkcí. Na rozdíl od Win16 jsou názvy všech funkcí Win32 API citlivé na přesné použití malých a velkých písmen (ve Win16 tomu tak nebylo). Pokud někde použijete místo velkého písmena malé nebo naopak, pak požadovaná funkce nebude nalezena. Dávejte si také pozor na správné použití koncovky A nebo W ve funkcích, které přebírají parametry řetězce. (Více o tom viz níže.)

10. Často si svou práci ukládejte. Chyby související s nesprávným použitím DLL a Win API mohou vést k pádu prostředí VB a možná i celého operačního systému. Měli byste se ujistit, že kód, který napíšete před spuštěním testu, je uložen. Nejjednodušší je nastavit moduly projektu na automatické nahrávání před spuštěním projektu ve VB.

Po přečtení předchozího tipu si možná myslíte, že používání funkcí Win API je riskantní záležitost. Do jisté míry je to pravda, ale pouze ve srovnání s bezpečným programováním, které poskytuje samotné VB. Ale při jejich šikovné aplikaci a znalosti možných úskalí je toto riziko minimální. Kromě toho je často prostě nemožné úplně opustit používání Win API - budou stále vyžadovány pro jakýkoli seriózní vývoj.

Kromě toho jsme již dříve zmínili „úskalí“ pro širokou třídu DLL. V případě Win API je vše mnohem jednodušší, jelikož forma volání těchto funkcí je zde jednoznačně sjednocena. Přitom je třeba mít na paměti následující klíčové body:

1. Funkce Win32 API jsou přesně funkce, tedy procedury typu Function (v Win16 API bylo mnoho Sub rutin). Toto jsou všechny funkce typu Long, takže jejich popisy jsou napsány následovně: Declare Function name ... As Long ‘ je explicitně definován typ funkce _

   Declare Function name& ‘ typ funkce _ je definován s příponou

   Volání funkce API vypadá takto:

Result& = ApiName& ([ ArgumentList]

1. Nejčastěji je návratovou hodnotou funkce výstupní kód operace. Navíc nenulová hodnota v tomto případě znamená normální dokončení, nula - chyba. Obvykle (ale ne vždy) můžete zkontrolovat povahu chyby voláním funkce GetLastError. Popis této funkce je následující: Declare Function GetLastError& Lib "kernel32" ()

   POZORNOST! Při práci ve VB je nejlepší použít vlastnost LastDLLError objektu Err k získání hodnoty upřesněného chybového kódu, protože VB někdy resetuje funkci GetLastError mezi voláním API a pokračováním ve vykonávání programu.

   Kód vrácený GelLastError můžete interpretovat pomocí konstant zapsaných v souboru API32.TXT s názvy začínajícími příponou ERROR_.

   Nejtypičtější chyby mají následující kódy:

   • ERROR_INVALID_HANDLE = 6& - neplatný popisovač
   • ERROR_CALL_NOT_IMPLEMENTED = 120& - volání ve Windows 9x funkce dostupná pouze pro Windows NT
   • ERROR_INVALID_PARAMETER = 87& - neplatná hodnota parametru

   Mnoho funkcí však vrací hodnotu některého požadovaného parametru (například OpenFile vrací hodnotu deskriptoru souboru). V takových případech je chyba definována nějakou jinou speciální hodnotou Return&, nejčastěji 0 nebo -1.

2. Rozhraní API Win32 používají přísně pevné způsoby předávání nejjednodušších datových typů. a) ByVal ... As Long

   Dlouhé proměnné zpracovávají alespoň 80 % předávání argumentů. Všimněte si, že argument Vždy následuje klíčové slovo ByVal, které mimo jiné znamená, že se provádí jednosměrný přenos dat - z programu VB do funkce API.

   B) ByVal ... Jako řetězec

   Tento typ přenosu dat je také docela běžný a také s argumentem Vždy ByVal je aplikován. Při volání funkce API se adresa řetězce zapíše do zásobníku, takže v tomto případě je možná obousměrná výměna dat. Při práci se strunami je třeba si uvědomit několik nebezpečí.

   První je, že paměť je ve volajícím programu vyhrazena pro řetězec, takže pokud bude funkce API plnit řetězce, pak před jejím voláním musíte vytvořit řetězec požadované velikosti. Například funkce GetWindowsDirectory vrátí cestu k adresáři Windows, který podle definice nesmí být delší než 144 znaků. Podle toho by volání této funkce mělo vypadat nějak takto:

   WinPath$ = Space$(144) ‘rezervní řetězec v _ 144 znacích Result& = GetWindowsDirectory& (WinTath$, 144) _ ‘buffer fill’ Result& - skutečný počet znaků v názvu adresáře _ WinPath$ = Left$(WinPath, Result&)

   Druhým problémem je, že při volání funkce API se zdrojový řetězec převede na nějakou jeho interní reprezentaci a naopak, když funkce skončí. Jestliže v době Win16 tato operace spočívala pouze v přidání nulového bajtu na konec řetězce, tak s příchodem Win32 se k tomu přidala i transformace dvoubajtového kódování Unicode na ANSI a naopak. (Toto bylo podrobně probráno v článku "Funkce práce s řetězcovými proměnnými ve VB", ComputerPress 10'99 a 01'2000). Prozatím si uvědomte, že pomocí konstrukce ByVal... As String můžete vyměňovat pouze řetězce se znakovými daty.

   C) ... Jako každý

   To znamená, že do zásobníku bude vsunuta nějaká adresa paměťového bufferu, jejíž obsah bude interpretovat funkce API například v závislosti na hodnotě jiných argumentů. Nicméně, As Any lze použít pouze v příkazu Declare - specifická proměnná musí být definována jako argument, když je provedeno specifické volání funkce.

   D) ... Jako UserDefinedType

   Taková konstrukce se také často používá, když je potřeba vyměňovat data (zpravidla oběma směry) pomocí nějaké struktury. Tento konstrukt je vlastně jakousi konkrétní implementací formuláře As Any transfer, jen je v tomto případě funkce nastavena na pevnou strukturu.

   Podoba datové struktury je definována konkrétní API funkcí a je na zodpovědnosti programátora, aby ji správně popsal a rezervoval ve volajícím programu. Takový design Vždy použitý bez slova ByVal, tedy v tomto případě se provede předávání odkazem - adresa proměnné se zapíše do zásobníku.

Příklad volání funkce API

Pojďme si výše uvedené ilustrovat na příkladu použití dvou užitečných souborových funkcí – lopen a lread , které jsou popsány následovně:

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

Ve VB jsou jejich protějšky - v tomto případě přesné - operátory Open a Get (pro binární režim). Okamžitě věnujte pozornost použití klíčového slova Alias ​​v deklaraci funkce - to je jen případ, kdy se bez něj neobejdete. Názvy skutečných funkcí v knihovně začínají podtržítkem (typický styl C), což není ve VB povoleno.

Operace otevření souboru může vypadat takto:

Const INVALID_HANDLE_VALUE = -1 ' neplatná _ hodnota manipulace lpFileName$ = “D:\calc.bas” ' název souboru wReadWrite& = 2 ' režim čtení a zápisu hFile& = lopen(lpFileName$, wReadWrite&) _ ' = definovat popisovač souboru If hFile_LEVALUE Potom _ ' chyba při otevírání souboru ' Zadání kódu chyby CodeError& = Err.LastDllError 'CodeError& = GetLastError _ ' tato konstrukce nefunguje End If

Zde je třeba věnovat pozornost dvěma bodům:

• jako hodnotu funkce získáme hodnotu deskriptoru souboru. Chyba odpovídá hodnotě -1;
• právě v tomto případě nefunguje volání funkce GetLastError - abychom získali upřesněnou chybovou hodnotu, obrátili jsme se na objekt Err (o možnosti takové situace jsme mluvili výše).

Poté můžete číst obsah souboru, ale to předpokládá, že programátor musí rozumět jeho struktuře (stejně jako se to stává při práci s libovolnými binárními soubory). V tomto případě může volání funkce lread vypadat takto:

Dim MyVar As Single wBytes = lread (hFile&, MyVar, Len(MyVar) ' čtení reálného čísla, 4 byty ' wBytes je počet skutečně přečtených dat, ' -1 je chyba... Typ MyStruct x As Single i As Integer End Type Dim MyVar As MyStruct wBytes = lread (hFile&, MyVar, Len(MyVar)) ' čtená datová struktura, 6 bajtů

Znovu si všimněte, že druhý argument funkce je předán odkazem, zbytek hodnotou.

Dim MyVar As String MyVar = Space$(10) 'rezervní proměnná pro 10 znaků wBytes = lread (hFile&, ByVal MyVar, Len(MyVar)) ' čtení řetězce znaků, 10 znaků

Zde můžete vidět důležitý rozdíl oproti předchozímu příkladu – řetězcová proměnná je nutně doprovázena klíčovým slovem ByVal.

Čtení obsahu souboru v poli (pro jednoduchost použijeme jednorozměrné bajtové pole) se provádí následovně:

Dim MyArray(1 až 10) As Byte wBytes = lread (hFile&, MyArray(1), _ Len(MyArray(1))* 10) ‘ čtení 10 prvků pole

Zadáním prvního prvku pole jako argumentu předáme adresu začátku oblasti paměti vyhrazené pro pole. Je zřejmé, že jakýkoli fragment pole lze vyplnit tímto způsobem:

WBytes = lread (hFile&, MyArray(4), _ Len(MyArray(1))* 5) ' čtení prvků pole od 4. do 8.

Tip 5: Použijte alias pro přenosy a parametry jako každý

Zde na základě předchozí ukázky odhalíme podstatu čtvrtého tipu Dana Applemana.

Při práci s funkcí lread byste měli pamatovat na to, že při přístupu k ní pomocí řetězcové proměnné musíte použít klíčové slovo ByVal (jinak se nelze vyhnout hlášení o nelegální operaci). Pro jistotu můžete vytvořit další speciální popis stejné funkce pro práci pouze s řetězcovými proměnnými:

Declare Function lreadString Lib "kernel32" _ Alias ​​​​"_lread" (_ ByVal hFile As Long, ByVal lpBuffer As Long, _ ByVal wBytes As Long) As Long

Při práci s tímto popisem již nemusíte zadávat ByVal při přístupu:

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

Zdálo by se, že syntaxe operátoru Declare umožňuje provést takovou speciální deklaraci pro pole:

Deklarujte funkci lreadString Lib „kernel32“ Alias ​​​​„_lread“ (_ ByVal hFile As Long, lpBuffer() As Byte, _ ByVal wBytes As Long) As Long

Nicméně odvolání

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

nevyhnutelně vede k fatální chybě programu.

Toto je pokračování rozhovoru o zvláštnostech zpracování řetězcových proměnných ve Visual Basic: VB používá dvoubajtové kódování Unicode, Win API používá jednobajtové kódování ANSI (navíc s formátem přijatým v C s nulovým bajtem na konci). Při použití řetězcových proměnných jako argumentu je tedy převod z Unicode na ANSI vždy automaticky proveden při volání funkce API (přesněji funkce DLL) a zpětný převod při návratu.

Závěr je jednoduchý: Řetězcové proměnné lze použít k výměně znakových dat, ale nelze je použít k výměně libovolných binárních informací (jako tomu bylo u 16bitových verzí VB). V druhém případě je lepší použít jednorozměrné bajtové pole.

Jak víte, typ String lze použít k popisu vlastní struktury. V tomto ohledu je třeba mít na paměti následující:

• Pro přístup k Win API je přísně zakázáno používat následující konstrukci: Type MyStruct x As Single s As String ‘ řetězec proměnné délky End Type

  V případě řetězce proměnné délky je jako součást struktury předán popisovač řetězce se všemi z toho vyplývajícími důsledky v podobě chyby při provádění programu.

• Jako prvek struktury můžete použít řetězec pevné délky: Type MyStruct x As Single s As String*8 ‘ řetězec pevné délky End Type

V tomto případě se provede odpovídající převod kódování.

A poslední poznámka: při přístupu k funkci API v žádném případě nemůžete použít pole řetězcových proměnných (pevné i proměnné délky). V opačném případě bude vznik „nezákonné operace“ zaručen.

Je pravděpodobné, že budete mít situaci, kdy budete potřebovat napsat své vlastní funkce DLL. Potřeba toho nevyhnutelně vyvstane, pokud použijete technologii smíšeného programování - použití dvou nebo více programovacích jazyků k implementaci jedné aplikace.

V tomto ohledu poznamenáváme, že smíšené programování je zcela běžné pro implementaci poměrně složité aplikace. Každý jazyk (přesněji programovací systém založený na jazyce) má totiž své silné a slabé stránky, takže je celkem logické využívat výhod různých nástrojů pro řešení různých problémů. Například VB - pro vytvoření uživatelského rozhraní, C - pro efektivní přístup k systémovým zdrojům, Fortran - pro implementaci numerických algoritmů.

Názor autora je následující: jakékoli seriózní programování vyžaduje, aby vývojář vlastnil alespoň dva nástroje. Samozřejmě v dnešních podmínkách jasné dělby práce je velmi těžké být vynikajícím odborníkem i ve dvou systémech, logičtější je proto schéma „hlavní a pomocný jazyk“. Myšlenka je taková, že i nepatrná znalost „pomocného“ jazyka (psaní poměrně jednoduchých postupů) může výrazně zlepšit efektivitu „hlavního“ jazyka. Všimněte si, že znalost VB, alespoň jako pomocná, je dnes pro profesionálního programátora téměř povinným požadavkem. Mimochodem, v dobách DOSu pro každého programátora, včetně Basicu, bylo velmi žádoucí znát základy Assembleru.

Tak či onak, ale i v podmínkách skupinové práce, kdy se každý programátor zabývá svým vlastním specifickým podnikáním, by všichni účastníci projektu měli mít představu o vlastnostech procedurálního rozhraní v různých jazycích. A vědět, že mnoho programovacích systémů (včetně VB) umožňuje kromě výchozího rozhraní používat další, rozšířené metody pro volání procedur, které umožňují přizpůsobit rozhraní jinému jazyku.

Při studiu interprocedurálního rozhraní byste měli věnovat pozornost následujícím možným „úskalím“:

• Různé jazyky mohou používat různé konvence pro zápis identifikátorů. Například je běžné používat podtržítko na začátku názvu procedury, což není ve VB povoleno. Tento problém lze snadno vyřešit použitím klíčového slova Alias ​​v příkazu Declare (viz například Tip 2-3).
• Lze použít jinou sekvenci zápisu předávaných argumentů do zásobníku. Například v dobách DOSu (abych byl upřímný - nevím, jak to teď vypadá v prostředí Windows), C psalo argumenty od konce seznamu, jiné jazyky​​(Fortran, Pascal, Basic ) - od začátku.
• Standardně se používají různé principy pro předávání parametrů – odkazem nebo hodnotou.
• Různé principy ukládání řetězcových proměnných. Například v C (stejně jako ve Fortranu a Pascalu) je délka řetězce určena prázdným bytem na jeho konci, zatímco v Basicu je délka zapsána explicitně v popisovači řetězce. Samozřejmě je potřeba pamatovat na možnost použití různých kódování znaků.
• Při přenosu vícerozměrných polí je třeba mít na paměti, že existují různé možnosti převodu vícerozměrných struktur na jednorozměrné (od prvního indexu nebo od posledního ve vztahu k dvojrozměrným polím - „po řádcích“ nebo „po sloupcích). “).

S ohledem na to lze učinit následující doporučení:

• Použijte nejjednodušší a osvědčené způsoby předávání argumentů funkcím DLL. Standardy přijaté pro Win API jsou docela vhodné jako model.
• Nikdy nepředávejte pole řetězcových proměnných.
• Buďte velmi opatrní při předávání jednoduchých řetězcových proměnných a vícerozměrných polí.
• Nezapomeňte speciálním způsobem zkontrolovat funkčnost mechanismu pro předávání argumentů do a z volané procedury. Napište vlastní test pro kontrolu přenosu dat. Samostatně zkontrolujte, zda je každý argument předán správně. Pokud máte například proceduru s několika argumenty, nejprve zkontrolujte správnost předání každého parametru pro variantu s jedním argumentem a teprve potom - pro celý seznam.

Co když je ale funkce DLL již napsaná například ve Fortranu, ale její vstupní rozhraní příliš nezapadá do výše uvedených standardů VB? Zde jsou dvě rady. Za prvé: napište testovací funkci DLL a použijte ji k pokusu a pokusu a omylu najít správné volání z programu VB. Za druhé: napište ve stejném Fortranu proceduru adaptéru, která by poskytla jednoduché rozhraní mezi VB a funkcí DLL s transformací jednoduchých datových struktur na složité (například převod vícerozměrného pole bajtů na pole řetězců).

Takže: použijte funkce DLL. Ale buďte ostražití...

ComputerPress 9 "2000

Začněme se základy: co je API? Zkratka znamená Application Programming Interface neboli rozhraní pro programování aplikací. Zdá se, že název mluví sám za sebe, ale je lepší zvážit podrobnější vysvětlení.

Jak již bylo zmíněno, API je především rozhraní. Rozhraní, které umožňuje vývojářům používat připravené bloky k sestavení aplikace. V případě vývoje mobilních aplikací může knihovna pro práci s „chytrou domácností“ fungovat jako API – všechny nuance jsou implementovány v knihovně a na toto API se ve svém kódu pouze odkazujete.

V případě webových aplikací může API vracet data v jiném formátu, než je standardní HTML, což usnadňuje použití při psaní vlastních aplikací. Veřejná rozhraní API třetích stran nejčastěji vracejí data v jednom ze dvou formátů: XML nebo JSON. V případě, že se rozhodnete vytvořit API pro vaši aplikaci, nezapomeňte, že JSON je mnohem výstižnější a snáze čitelný než XML a služby, které poskytují přístup k datům ve formátu XML, to druhé postupně vyřazují.

API ve webových aplikacích na příkladech

Aplikace – například Github – má své vlastní API, které mohou používat ostatní vývojáři. Jak jej využijí, záleží na možnostech, které API poskytuje a jak dobře funguje představivost vývojářů. Github API umožňuje například získat informace o uživateli, jeho avataru, čtenářích, úložištích a mnoho dalších užitečných a zajímavých informací.

Podobně můžete odeslat požadavek v jakémkoli jazyce, včetně Ruby. Odpověď na žádost bude asi tato:

( "login" : "Freika" , "id" : 3738638, "avatar_url" : "https://avatars.githubusercontent.com/u/3738638?v=3", "gravatar_id" : "" , "url" : "https://api.github.com/users/Freika", "html_url" : "https://github.com/Freika" , "followers_url" : "https://api.github.com/users/Freika/followers", "following_url" : "https://api.github.com/users/Freika/following(/other_user)", "gists_url" : "https://api.github.com/users/Freika/gists(/gist_id)", "starred_url" : "https://api.github.com/users/Freika/starred(/owner)(/repo)", "subscriptions_url" : "https://api.github.com/users/Freika/subscriptions", "organizations_url" : "https://api.github.com/users/Freika/orgs", "repos_url" : "https://api.github.com/users/Freika/repos", "events_url" : "https://api.github.com/users/Freika/events(/privacy)", "received_events_url" : "https://api.github.com/users/Freika/received_events", "type" : "User" , "site_admin" : false , "name" : "Evgeniy" , "company" : "" , "blog" : "http://frey.su/" , "location" : " Barnaul" , "email" : "" , "najímatelné" : true , "bio" : null, "public_repos" : 39, "public_gists" : 13, "followers" : 15, "followers" : 21, "created_at" : "2013-03-01T13:48:52Z" , "updated_at" : "2014-12-15T13:55:03Z" )

Jak můžete vidět z bloku výše, odpověď obsahuje přihlašovací jméno, avatar, odkaz na profil na webu a v API, stav uživatele, počet veřejných úložišť a další užitečné a zajímavé informace.

Jedno API nestačí

Vytvoření plnohodnotného API pro vaši aplikaci je jen polovina úspěchu. Jak se k API dostanete? Jak k němu budou vaši uživatelé přistupovat?

První věc, která vás napadne, je obvyklá série požadavků HTTP za účelem získání požadovaných informací, a to je špatná odpověď. Nejviditelnější způsob v tomto případě není nejpohodlnější a nejjednodušší. Mnohem rozumnější by bylo vytvořit speciální knihovnu pro práci s rozhraním, která bude popisovat všechny potřebné způsoby přijímání a odesílání informací pomocí API.

Opět použijeme Github jako příklad: pro práci s API této skvělé služby (a její rozhraní poskytuje rozsáhlé možnosti) bylo vytvořeno několik knihoven v různých jazycích, například drahokam Octokit. V dokumentaci pro takové knihovny (a klenotu uvedeném jako příklad) bude každý zainteresovaný vývojář schopen najít všechny potřebné způsoby, jak získat informace z Github a odeslat je zpět prostřednictvím rozhraní API služby.

Pokud tedy vytváříte vlastní API, přemýšlejte o vytvoření knihoven pro práci s ním také v nejběžnějších jazycích. A připravte se, že při určité úrovni poptávky po vaší aplikaci si někdo jiný může vytvořit vlastní knihovnu pro práci s vaším API. Tohle je fajn.

užitečné odkazy

V dalších článcích si povíme, jak správně vytvořit API, zajistit jeho bezpečnost a omezit přístup k některým informacím.

Dříve nebo později se každý programátor setká s takovým konceptem, jako je API. Když však k takovému setkání dojde, ne každý ví, co to je, proč je to potřeba a jak to používat. A v tomto článku se chystám vyplnit tuto mezeru ve znalostech některých z vás a také uvést příklad ze své praxe.

API (rozhraní pro programování aplikací) - Tento rozhraní pro programování aplikací. Zjednodušeně řečeno se jedná o sadu různých funkcí, konstant, tříd, formátů dotazů, které lze použít v jiných programech.

Dá se to považovat API je určitý objekt, jehož implementaci neznáme, nicméně můžeme jej použít. Například počítač je objekt, jehož implementaci zná jen velmi málo lidí, nicméně téměř každý jej může používat prováděním některých akcí: sledováním videa, surfováním na internetu, tiskem textu a tak dále. Málokdo ví, jak to všechno funguje, ale zvládne to téměř každý.

Příklad API je Windows API, OpenGL API, Direct3D API a tak dále.

Například, není to tak dávno, co jsem také narazil přímo na API. Zaregistroval jsem se do služby mailing listu SmartResponder.ru"a spustil mailing list, do kterého se lidé začali přihlašovat. Úkol byl následující: do jednoho dne po přihlášení si člověk může koupit můj placený videokurz se slevou. Protože všechny informace o předplatitelích jsou uloženy na serveru" SmartResponder.ru“, pak normální přístup (například přes DB) K těmto údajům jsem neměl přístup, ale bylo nutné je implementovat. Dobře, ty" SmartResponder.ru"mít svůj vlastní API, který jsem použil.

Našel jsem v nich API formát dotazu pro získání data předplatného jako výsledek. Procházím kučera Odeslal jsem odpovídající žádost a obdržel jsem požadované datum předplatného pro konkrétní položku emailová adresa. Dále standardní zpracování a výstup výsledku.

API mohou být zábavná i frustrující zároveň. Na jedné straně interakcí s jinými aplikacemi můžete výrazně zvýšit dosah publika a „wow efekt“ vaší aplikace. Na druhou stranu to zahrnuje čtení tuny dokumentace, učení se o autentizačních strategiích a analýzu neinformativních (nebo dokonce chybějících) chybových zpráv.

Za prvé, pokud stále úplně nerozumíte tomu, co je API (Application Programming Interface), přečtěte si vysvětlení Skillcrush a poté první část tohoto článku, abyste to dohnali.

„API“ je neuvěřitelně široký pojem – pokaždé, když vaše aplikace „komunikuje“ s jinou aplikací, je to prostřednictvím nějakého druhu API. Komponenty ve vaší vlastní aplikaci, stejně jako různé části Rails, spolu také komunikují prostřednictvím API. Jsou to víceméně nezávislé dílčí aplikace, které předávají data, která každá potřebuje k provádění svých vlastních specifických úkolů. Ve světě aplikací je všechno API!

Když vytvoříte aplikace s dynamičtějšími front-endovými funkcemi (jak jednostránkové Javascriptové aplikace, tak jednoduché aplikace se samostatnými voláními AJAX), budou komunikovat s backendem Rails prostřednictvím vašeho vlastního API, což je ve skutečnosti jen jeden nebo tři řádky kódu navíc. ., sdělující vašim kontrolérům, jak obsluhovat JSON nebo XML místo HTML.

V tomto tutoriálu se naučíte, jak vytvořit vlastní API. V následujících lekcích se budeme zabývat tím, jak interagovat s rozhraními API jiných aplikací. Lekce by měly být dobrým odrazovým můstkem pro učení o tomto tématu, ale je nepravděpodobné, že budou schopny plně pokrýt všechny případy. Velkou součástí práce s API je schopnost číst jejich dokumentaci a zjistit, co od vás chtějí.

Body k zamyšlení

Projděte si otázky a zjistěte, zda znáte odpovědi. Po dokončení úkolu se znovu zkontrolujte.

• Jak Rails rozumí, jaký typ souboru očekáváte jako odpověď, když odešlete požadavek HTTP.
• Jaký je účel metody #respond_to?
• Jak vrátíte objekt uživatele (User) při specifikaci atributů, které nechcete do tohoto objektu zahrnout (tj. nemůžete jen vrátit User.first)?
• Pojmenujte 2 kroky ze zákulisí metody #to_json.
• Jak přiznám akci ovladače, aby vykreslila pouze chybovou zprávu?
• Jak vytvořit vlastní chybovou zprávu?
• Proč nemůžete použít metody ověřování řadiče založené na relaci, pokud chcete povolit programové připojení k vašemu API?
• Co je to „architektura orientovaná na služby“?

Základy API

Vaše aplikace Rails je ve skutečnosti již API, i když si to možná jako API nemyslíte. Webový prohlížeč, který vaši uživatelé spouštějí, je také program, takže ve skutečnosti odešle požadavek API do vaší aplikace Rails, když uživatel otevře novou stránku. Máme tendenci uvažovat tímto způsobem, protože vykreslování HTML šablon je tak běžný úkol, že tuto funkcionalitu jednoduše zakódujeme do našich serverových programů jako standardní typ odezvy a vše ostatní považujeme za něco neobvyklého.

Často však chcete podat požadavek, který nevyžaduje, abyste museli projít všemi bolestmi hlavy při používání prohlížeče. Možná vám nezáleží na struktuře stránky (HTML), ale na oplátku chcete čistá data. Řekněme, že chcete získat seznam všech uživatelů. Můžete požádat o něco jako http://yourapplication.com/users , což pravděpodobně spustí akci #index a vykreslí seznam všech uživatelů aplikace.

Ale proč se zatěžovat všemi těmito informacemi navíc, když jediné, co chcete, je seznam uživatelů? Nejjednodušší možností by bylo odeslat požadavek na stejnou adresu URL s uvedením očekávání odpovědi JSON nebo XML na oplátku. Pokud správně nastavíte řadič Rails, získáte zpět jednoduchý objekt pole JSON obsahující všechny uživatele. Báječné!

Stejný princip platí, když komunikujete s externím API. Řekněme, že chcete získat nejnovější „tweety“ uživatele z Twitteru. Vše, co musíte udělat, je sdělit své aplikaci Rails, jak interagovat s Twitter API (tj. ověřit se), odeslat požadavek a zpracovat sadu „tweetů“, které budou vráceny.

Vytvoření API

Možná budete chtít ze své aplikace Rails udělat čisté back-endové API pro webové stránky front-endu, nebo se prostě chtít naučit, jak odeslat JSON, když to front-end požaduje. Tato část se nebude zabývat tím, jak vytvořit plnohodnotná RESTful API s funkcí ověřování. Toto je hladký úvod do zacházení s vaší aplikací jako s API.

Základy

Pokud chcete, aby vaše aplikace Rails vracela JSON místo HTML, budete muset svému řadiči říci, aby to udělal. Skvělá věc je, že stejná akce ovladače může vrátit různé typy v závislosti na tom, zda váš uživatel zadává běžný požadavek prohlížeče nebo přistupuje k rozhraní API prostřednictvím příkazového řádku. To určuje, jaký typ požadavku byl proveden na základě přípony požadovaného souboru, jako je example.xml nebo example.json .

Můžete zkontrolovat, co si Rails "myslí" o typu souboru, který očekáváte, zkontrolováním protokolu serveru:

Zahájeno GET "/posts/new" pro 127.0.0.1 dne 2013-12-02 15:21:08 -0800 Processing by PostsController#new as HTML

První řádek vám říká, jaké URL bylo požadováno, a druhý vám říká, kam bylo směrováno a jak s ním Rails nakládá. Pokud byste použili rozšíření .json, vypadalo by to takto:

Zahájeno GET "/posts.json" pro 127.0.0.1 dne 2013-12-04 12:02:01 -0800 Zpracování PostsController#index jako JSON

Pokud máte spuštěnou testovací aplikaci, zkuste požádat o jiné adresy URL. Pokud váš kontrolér neví, jak s nimi zacházet, můžete dostat chybu, ale přesto byste měli být schopni vidět, co Rails rozumí vašim požadavkům.

Vykreslování JSON nebo XML

Když se rozhodnete, že chcete odpovědět pomocí JSON nebo XML, budete muset svému řadiči sdělit, aby místo HTML vykreslil JSON nebo XML. Jedním ze způsobů, jak toho dosáhnout, je použít metodu #respond_to:

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

V tomto případě #respond_to předá do bloku objekt formátu, ke kterému můžete připojit příslušné vykreslovací volání. Pokud nic neuděláte, html se vykreslí pomocí standardní šablony Rails (v tomto příkladu app/views/index.html.erb).

Funkce #render je dostatečně chytrá, aby pochopila, jak vykreslovat širokou škálu formátů. Když mu předáte klíč:json , zavolá #to_json na hodnotě, v tomto příkladu @users . Tím se vaše objekty Ruby převedou na řetězce JSON, které budou předány žádající aplikaci.

Takto získáte své API. Samozřejmě, že vytvoření API může být trochu složitější, pokud chcete dělat nějaké fantastické věci, ale je to všechno o základech.

Určení návratových atributů

Řekněme, že se chcete ujistit, že nevracíte e-mailovou adresu uživatele spolu s objektem uživatele. V tomto případě budete chtít změnit atributy, které budou vráceny, a upravit to, co dělá metoda #to_json.

Dříve byste svou verzí jednoduše přepsali metodu #to_json, ale nyní to již nemusíte – ve skutečnosti místo toho přepíšete metodu #as_json. Metoda #as_json se používá v metodě #to_json, takže její úprava implicitně změní výsledek #to_json , ale poněkud specifickým způsobem.

#to_json dělá 2 věci: spustí #as_json a získá hash atributů, které se mají vykreslit do JSON. Poté se vykreslí do JSON pomocí ActiveSupport::json.encode . Takže úpravou #as_json jste konkrétnější o části metody #to_json, kterou skutečně chcete změnit.

V našem případě to uděláme úpravou #as_json v našem modelu tak, aby vrátil pouze atributy, které potřebujeme:

# app/models/user.rb class User< ActiveRecord::Base # Вариант 1: Полное переопределение метода #as_json def as_json(options={}) { :name =>self.name ) # NEZAHRNUJTE pole email end # Možnost 2: Použijte standardní metodu #as_json def as_json(options=()) super(pouze: [:name]) end end

Pak v našem ovladači vše, co musíme udělat, je vykreslit JSON jako normálně (příklad níže vždy vrátí JSON, ať už byl požadavek HTML odeslán nebo ne):

# app/controllers/users_controller.rb třída UsersController< ApplicationController def index render json: User.all end end

Pamatujte, že když používáte #render, nemusíte volat #to_json sami – udělá to za vás.

Někdy může Heroku vyžadovat další kroky, aby se správně zobrazily vaše chybové stránky. Dívej se. Možná budete muset nejprve odstranit statické stránky z adresáře app/public.

Zajištění zvenčí

Řekněme, že chcete povolit přístup k API pouze v případě, že je uživatel přihlášen. Vaše stávající ověření řadiče již funguje – jen se ujistěte, že máte nastaveno správné #before_action (např. before_action:require_login). Možná budete chtít funkcionalitu, ve které mohou stránku zobrazit přihlášení i nepřihlášení uživatelé, ale každý potřebuje vidět jiná data. Nechcete, aby nepřihlášení uživatelé mohli zadávat požadavky API na načtení citlivých dat. Stejně tak nechcete povolit neoprávněným uživatelům návštěvu určitých stránek HTML.

Pokud chcete zpracovávat požadavky z jiné aplikace než prohlížeče (například z příkazového řádku), nemůžete se při ověřování spoléhat na soubory cookie prohlížeče. To je důvod, proč většina rozhraní API používá nativní tokeny jako součást procesu ověřování. O tokenech si povíme trochu více v příštím tutoriálu.

Další kroky

Nyní máte dovednosti používat svou aplikaci Rails nejen pro HTML, ale pro jakýkoli jiný formát. Pokud chcete jít dále a nechat ostatní vývojáře, aby vytvořili věci pomocí vaší platformy (například aby mohli zadávat programové požadavky namísto autentizace jako uživatel), budete muset svůj systém API mnohem lépe zabezpečit. Nebudeme se zde zabývat vším, ale podívejte se na následující:

• Článek Building Awesome Rails API popisuje mnoho z nejlepších přístupů k přechodu z hračkářské aplikace na průmyslová standardní rozhraní API.

Servisně orientovaná architektura

Je čas představit architektonický přístup nazvaný Service-Oriented Architecture (SOA). Základní myšlenkou je, že vaše aplikace se bude skládat z mnoha služeb, jako je platební systém, registrace uživatele, modul doporučení atd. Místo toho, abyste to všechno stavěli do jedné hlavní aplikace, rozdělujete subsystémy na zcela nezávislé části, které spolu komunikují pomocí interních rozhraní API.

To je dobré z mnoha důvodů. Tím, že zajistíte, že každé části vaší aplikace bude jedno, jak fungují ostatní části a bude vědět, jak si data vyžádat pouze prostřednictvím jejich API, můžete provést významné změny v kódu služby a zbytek aplikace bude fungovat jako předtím. Jednu službu můžete zcela nahradit jinou, a pokud bude komunikovat pomocí stejných metod API, půjde to velmi hladce. Můžete použít externí API jako součást vaší aplikace (jako jsou platební procesory) namísto psaní vlastních. Můžete vytvořit aplikaci PHP, která spolupracuje s aplikací Python, která spolupracuje s aplikací Rails, a vše bude fungovat, protože spolu komunikují pomocí API.

Obecně je dobré snažit se, aby každá část vaší aplikace byla co nejvíce nezávislá. Koncept SOA vás vybízí k tomu, abyste přemýšleli přesně o tom, jaké metody chcete vystavit ostatním částem vaší aplikace, a vylepší váš kód. Za předpokladu, že každá hlavní součást vaší aplikace je nezávislá, můžete navíc mnohem snadněji izolovat problémy a inteligentněji řešit chyby.

Použití architektury orientované na služby pro celou aplikaci je jako rozdělit obří, komplexní skript Ruby na šikovné třídy a metody, pouze ve větším měřítku.

Jedním z nejznámějších případů přechodu na architekturu orientovanou na služby je Amazon.com. Jednoho dne v roce 2002 Jeff Bezos bez obalu prohlásil, že všechny pracovní týmy musí přejít na SOA, jinak budou vyhozeny. Notoricky známý blogový příspěvek zaměstnanec společnosti Google, určený pro interní účely, ale náhodně vystavený veřejnosti, hovořil o síle Amazonu pomocí SOA. Je to skvělé čtení, takže ho určitě ohodnoťte, ale hlavní teze Bezosova dopisu jsou vyňaty v následujících citacích z příspěvku:

1) Všechny příkazy nyní poskytují svá data a funkce prostřednictvím rozhraní služeb.

2) Týmy spolu musí komunikovat prostřednictvím těchto rozhraní.

3) Jiné formy meziprocesové komunikace jsou zakázány: žádné přímé vazby, žádné přímé čtení dat z jiného příkazu, žádné modely sdílené paměti, žádná „zadní vrátka“ a podobně. Jediným povoleným způsobem komunikace je přístup k rozhraní služby přes síť.

4) Nezáleží na tom, jakou technologii používají. HTTP, Corba, Pubsub, nativní protokoly – na tom nezáleží. Bezosovi je to jedno.

5) Všechna servisní rozhraní bez výjimky musí být zpočátku navržena s možností ovládání zvenčí. To znamená, že tým musí plánovat a navrhovat, aby byl schopen poskytnout rozhraní vývojářům mimo společnost. Žádné vyjímky.

6) Každý, kdo bude ignorovat tyto požadavky, bude propuštěn.

SOA je vážná věc. Jistě, při jeho používání se objevuje spousta problémů – podívejte se na tento příspěvek o „poučeních“ Amazonu – ale má to neuvěřitelné množství výhod.

Při vytváření „hračkových“ aplikací si pravděpodobně nebudete se SOA příliš lámat hlavu, ale tato otázka vás určitě napadne, když začnete pracovat pro IT společnost, takže je dobré se s ní seznámit.

Váš cíl

1. Přečtěte si část 7 příručky Rails Guide to Controllers, kde se dozvíte o vykreslování JSON a XML.
2. Není nutné je sledovat (protože jdou o něco dále, než na co jsme aktuálně připraveni), ale pokud vás to zajímá, podívejte se na Railscasts v sekci Další zdroje ve spodní části tutoriálu, kde se dozvíte více o výhody API.

Závěr

Během kurzu Javascript budeme blíže spolupracovat s vaší aplikací jako API. V tomto kurzu vytvoříte několik full-stack aplikací, které používají volání AJAX pro lepší uživatelský zážitek, což ve skutečnosti zahrnuje vykreslování dat XML nebo JSON namísto úplné stránky HTML. Poté vytvoříte několik jednostránkových Javascript aplikací, které se spoléhají na API poskytované vaší aplikací Rails, aby získaly všechna potřebná data z databáze, a jinak běží na straně klienta (v prohlížeči).

Nejlepší způsob, jak se vypořádat s API, je vytvořit ho a pracovat s ním, na což se zaměříme v našich projektech.