Deze korte termijn is bekend bij iedereen die op zijn minst enige ervaring heeft met ontwikkelen. Maar niet iedereen begrijpt wat het precies betekent en waarom het nodig is. Ontwikkelaar Peter Gazarov sprak in eenvoudige woorden over de API op zijn blog.

De afkorting API staat voor “Application Programming Interface” (application programming interface, application programming interface). De meeste grote bedrijven ontwikkelen op een gegeven moment API's voor klanten of voor intern gebruik. Om te begrijpen hoe en hoe API's worden gebruikt in de ontwikkeling en het bedrijfsleven, moet u eerst begrijpen hoe het World Wide Web werkt.

World Wide Web en externe servers

Het WWW kan worden gezien als een enorm netwerk van onderling verbonden servers waarop elke pagina is opgeslagen. Van een gewone laptop kan een server worden gemaakt die een hele website op het netwerk kan bedienen, en ontwikkelaars gebruiken lokale servers om websites te maken voordat ze deze voor een breed scala aan gebruikers openen.

Wanneer ingevoerd in de adresbalk van de browser www.facebook.com Een overeenkomstig verzoek wordt naar de externe Facebook-server verzonden. Zodra de browser het antwoord ontvangt, interpreteert deze de code en geeft de pagina weer.

Elke keer dat een gebruiker een pagina op internet bezoekt, communiceert hij met de API van de externe server. Een API is een onderdeel van de server dat verzoeken ontvangt en antwoorden verzendt.

API als een manier om klanten te bedienen

Veel bedrijven bieden API’s aan als kant-en-klaar product. Weather Underground verkoopt bijvoorbeeld toegang tot zijn weergegevens-API.

Gebruiksscenario: Op de website van een klein bedrijf staat een formulier voor het maken van afspraken voor klanten. Het bedrijf wil Google Agenda erin integreren, zodat klanten automatisch een evenement kunnen aanmaken en details over een aanstaande vergadering kunnen invoeren.

API-toepassing: Het doel is dat de siteserver rechtstreeks contact opneemt met de Google-server met het verzoek om een ​​evenement aan te maken met de opgegeven details, het antwoord van Google te ontvangen, dit te verwerken en de juiste informatie naar de browser te sturen, bijvoorbeeld een bericht waarin om bevestiging wordt gevraagd de gebruiker.

Als alternatief kan de browser een verzoek indienen bij de server-API van Google zonder via de server van het bedrijf te gaan.

Waarin verschilt de Google Agenda-API van de API van andere externe servers in het netwerk?

Technisch gezien zit het verschil in het formaat van het verzoek en het antwoord. Om een ​​volledige webpagina te genereren, verwacht de browser een reactie in HTML-opmaaktaal, terwijl de Google Agenda-API eenvoudigweg gegevens retourneert in een formaat zoals JSON.

Als een verzoek aan de API wordt gedaan door de server van de website van een bedrijf, dan is dit de client (net zoals de browser de client is wanneer de gebruiker de website opent).

Dankzij de API krijgt de gebruiker de mogelijkheid om een ​​actie uit te voeren zonder de website van het bedrijf te verlaten.

De meeste moderne websites gebruiken op zijn minst enkele API's van derden. Voor veel taken zijn al kant-en-klare oplossingen beschikbaar die worden aangeboden door externe ontwikkelaars, of het nu een bibliotheek of een dienst is. Vaak is het eenvoudiger en betrouwbaarder om gebruik te maken van een kant-en-klare oplossing.

Veel ontwikkelaars distribueren de applicatie naar verschillende servers, die met elkaar communiceren via de API. Servers die een ondersteunende functie vervullen voor de hoofdapplicatieserver worden microservices genoemd.

Wanneer een bedrijf dus een API aan zijn gebruikers aanbiedt, betekent dit eenvoudigweg dat het een reeks speciale URL's heeft gemaakt die alleen gegevens als reactie retourneren.

Dergelijke verzoeken kunnen vaak via een browser worden verzonden. Omdat HTTP-gegevensoverdracht in tekstvorm plaatsvindt, kan de browser het antwoord altijd weergeven. Via een browser kunt u bijvoorbeeld rechtstreeks toegang krijgen tot de GitHub API (https://api.github.com/users/petrgazarov), zonder toegangstoken, en dit antwoord ontvangen in JSON-formaat:

De browser geeft perfect het JSON-antwoord weer, dat in de code kan worden ingevoegd. Het is eenvoudig genoeg om gegevens uit dergelijke tekst te halen en deze naar eigen goeddunken te gebruiken.

Nog enkele API-voorbeelden

Het woord "toepassing" kan verschillende betekenissen hebben. In de context van de API betekent dit:

• een stukje software met een specifieke functie,
• de gehele server, de gehele applicatie, of slechts een apart deel van de applicatie.

Elk stukje software dat duidelijk te onderscheiden is van de omgeving, kan de letter “A” in een Engelse afkorting vervangen, en kan ook over een soort API beschikken. Wanneer een ontwikkelaar bijvoorbeeld een bibliotheek van derden in de code implementeert, wordt deze onderdeel van de gehele applicatie. Als zelfstandig stukje software zal de bibliotheek een soort API hebben waarmee deze kan communiceren met de rest van de applicatiecode.

Bij objectgeoriënteerd ontwerpen wordt code weergegeven als een verzameling objecten. In een toepassing kunnen honderden van dergelijke objecten met elkaar communiceren. Elk van hen heeft zijn eigen API - een set publiek eigenschappen en methoden voor interactie met andere objecten in de toepassing. Objecten kunnen dat ook hebben privé, interne logica die verborgen is voor de omgeving en geen API is.

Laten we beginnen met de basis: wat is een API? De afkorting staat voor Application Programming Interface, of interface voor applicatieprogrammering. De naam lijkt voor zichzelf te spreken, maar het is beter om een ​​meer gedetailleerde uitleg te overwegen.

Zoals eerder vermeld is een API in de eerste plaats een interface. Een interface waarmee ontwikkelaars kant-en-klare blokken kunnen gebruiken om een ​​applicatie te bouwen. In het geval van het ontwikkelen van mobiele applicaties kan een bibliotheek voor het werken met een smart home fungeren als een API - alle nuances zijn in de bibliotheek geïmplementeerd en u heeft alleen toegang tot deze API in uw code.

In het geval van webapplicaties kan de API gegevens retourneren in een ander formaat dan standaard HTML, waardoor het handig is om te gebruiken bij het schrijven van uw eigen applicaties. Openbare API's van derden leveren gegevens meestal in een van de volgende twee formaten: XML of JSON. Als u besluit een API voor uw toepassing te maken, bedenk dan dat JSON veel beknopter en gemakkelijker te lezen is dan XML, en dat services die toegang bieden tot gegevens in XML-formaat geleidelijk dit laatste verlaten.

API in webapplicaties met voorbeelden

Een applicatie – bijvoorbeeld Github – heeft een eigen API waar andere ontwikkelaars gebruik van kunnen maken. Hoe ze het zullen gebruiken, hangt af van de mogelijkheden die de API biedt en van hoe goed de verbeelding van de ontwikkelaars werkt. Met de GitHub API kan bijvoorbeeld informatie worden verkregen over de gebruiker, zijn avatar, lezers, repositories en vele andere nuttige en interessante informatie.

Op een vergelijkbare manier kunt u een verzoek in elke taal verzenden, inclusief Ruby. Het antwoord op het verzoek zal ongeveer de volgende informatie bevatten:

( "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://github.com/Freika" , "followers_url" : "https://api.github.com/users/Freika/followers", "volgende_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)", "abonnements_url" : "https://api.github.com/users/Freika/subscriptions", "organisaties_url" : "https://api.github.com/users/Freika/orgs", "repos_url" : "https://api.github.com/users/Freika/repos", "evenementen_url" : "https://api.github.com/users/Freika/events(/privacy)", "ontvangen_gebeurtenissen_url" : "https://api.github.com/users/Freika/received_events", "type" : "Gebruiker" , "site_admin" : false , "name" : "Evgeniy" , "company" : "" , "blog" : "http://frey.su/" , "location" : " Barnaul" , "email" : "" , "hireable" : true , "bio" : null, "public_repos" : 39, "public_gists" : 13, "followers" : 15, "following" : 21, "created_at" : "2013-03-01T13:48:52Z" , "updated_at" : "2014-12-15T13:55:03Z" )

Zoals uit het bovenstaande blok te zien is, bevat het antwoord de login, avatar, link naar het profiel op de site en in de API, gebruikersstatus, aantal openbare repositories en andere nuttige en interessante informatie.

API alleen is niet genoeg

Het creëren van een volwaardige API voor uw applicatie is slechts het halve werk. Hoe moet je toegang krijgen tot de API? Hoe krijgen uw gebruikers er toegang toe?

Het eerste dat in je opkomt is de gebruikelijke reeks HTTP-verzoeken om de gewenste informatie te verkrijgen, en dit is het verkeerde antwoord. De meest voor de hand liggende methode is in dit geval niet de handigste en eenvoudigste. Het zou veel redelijker zijn om een ​​speciale bibliotheek te creëren voor het werken met de interface, die alle noodzakelijke manieren beschrijft om informatie te ontvangen en te verzenden met behulp van de API.

Laten we Github nogmaals gebruiken om een ​​voorbeeld te geven: om met de API van deze uitstekende service te werken (en de interface biedt uitgebreide mogelijkheden), zijn er verschillende bibliotheken in verschillende talen gemaakt, bijvoorbeeld de Octokit-edelsteen. In de documentatie voor dergelijke bibliotheken (en het juweeltje dat als voorbeeld wordt gegeven) kan elke geïnteresseerde ontwikkelaar alle noodzakelijke manieren vinden om informatie van Github te ontvangen en terug te sturen via de service-API.

Als u dus uw eigen API maakt, overweeg dan misschien om bibliotheken te creëren om ermee te werken in de meest voorkomende talen. En wees erop voorbereid dat bij een bepaald niveau van vraag naar uw applicatie iemand anders zijn eigen bibliotheek kan maken om met uw API te werken. Dit is prima.

Nuttige links

In de volgende artikelen zullen we praten over hoe je een API correct kunt maken, de veiligheid ervan kunt garanderen en de toegang tot bepaalde informatie kunt beperken.

In dit bericht heb ik geprobeerd informatie te verzamelen die nuttig kan zijn voor testers die willen weten wat een API is. Ik hoop dat mensen die ervaring hebben met API-testen ook iets nuttigs zullen vinden. Nou ja, of help me in ieder geval fouten in mijn artikel te vinden :)
Wat is een API

API (Application Programming Interface) is een reeks kant-en-klare klassen, procedures, functies, structuren en constanten die door een applicatie (bibliotheek, service) worden geleverd voor gebruik in externe softwareproducten (Wikipedia).

Met andere woorden: de API geeft ons de mogelijkheid om het werk van anderen voor onze eigen doeleinden te gebruiken. De eerste keer dat ik een API tegenkwam, was de Windows API. Dit is een reeks functies die kunnen worden gebruikt door elke applicatie die op een bepaald besturingssysteem draait. Het kan bijvoorbeeld standaardfuncties gebruiken om de interface weer te geven.

Moderne API's nemen vaak de vorm aan van webservices die informatie verstrekken aan gebruikers (zowel mensen als andere webservices). Doorgaans zijn de informatie-uitwisselingsprocedure en het gegevensoverdrachtformaat zo gestructureerd dat beide partijen weten hoe ze met elkaar moeten communiceren.

Op de website https://dev.hh.ru/ (meer precies: https://github.com/hhru/api/blob/master/docs/general.md) kun je een beschrijving vinden van hoe HeadHunter API-clients en diensten communiceren met elkaar. Bijvoorbeeld een quote van de site:

• Alle API's werken via het HTTPS-protocol.
• Autorisatie wordt uitgevoerd met behulp van het OAuth2-protocol.
• Alle gegevens zijn alleen beschikbaar in JSON-formaat.
• Basis-URL - https://api.hh.ru/
• Datums worden opgemaakt volgens ISO 8601: JJJJ-MM-DDTuu:mm:ss±hhmm

U kunt de HH API lezen - het is een goed voorbeeld van gebruikersdocumentatie.

Formaten voor gegevensoverdracht

Er zijn veel gegevensformaten waarmee gebruikers communiceren met API's. Bijvoorbeeld het bekende XML. Of JSON - een lichtgewicht en ongecompliceerd formaat dat er als volgt uitziet:

("id": "0001", "type": "donut", "name": "Taart", "image": ( "url": "images/0001.jpg", "width": 200, "height ": 200 ) ) P oh ss Hieronder zie je de antwoorden vandaan komen MediaWikiAPI , in verschillende formaten :

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 ( voorzichtig, zal gebeuren met schommelen bestand)

HTTP g lagolen

Gebruikelijk N Bij toegang tot de web-APIgebruiken Er zijn allemaal HTTP-verzoeken . Dat is waaromIk moet er op zijn minst kort over zeggen standaard methoden, die erin kan zitten HTTP-verzoek . Deze methoden ook wel HTTP-werkwoorden genoemd :

• KRIJGEN. Waarschijnlijk het meest populaire type verzoek. Wordt gebruikt om gegevens te ontvangen of te lezen.
• NEERZETTEN. Aangepast N over en sp Wordt gebruikt om een ​​bron bij te werken .
• NA. Meestal gebruikt om een ​​nieuwe resource te maken.
• VERWIJDEREN. Verwijdert gegevens.
• En anderen

Als we informatie over een hulpbron willen krijgen,URI waarvan http://www.example.com/customers/12345 , kunnen we een verzoek sturen:
KRIJG http://www.example.com/customers/12345

Als we een bron willen bijwerken - we kunnen een PUT-verzoek sturen:
ZET http://www.example.com/customers/12345/orders/98765

Een webbrowser kan regelmatig GET-verzoeken verzenden. Voor het verzenden van andere soorten verzoeken zijn mogelijk scripttalen of speciale tools nodig (meer hierover hieronder).

Over HTTP methoden kunnen in meer detail worden gelezen bij op W iki.

HTTP tot odes van antwoorden

De server kan verschillende codes verzenden als reactie op gebruikersverzoeken. Dit kunnen foutcodes zijn of eenvoudigweg codes die gebruikers informeren over de status van de server. Een gedetailleerde beschrijving is wederom te vinden op de wiki.

De meest bekende codes zijn 4xx (problemen aan de clientzijde) en 5xx (problemen aan de serverzijde). Het is aan de API-ontwikkelaars zelf om te beslissen welke codes ze in een bepaalde situatie retourneren. De API van de Odnoklassniki-website retourneert bijvoorbeeld codes, waarvan de beschrijving te vinden is op de pagina https://apiok.ru/wiki/pages/viewpage.action?pageId=77824003.

Daarnaast raad ik je aan om naar het Request-Response-nummer te luisteren - het is eenvoudig en duidelijk over de codes die worden geretourneerd in HTTP-verzoeken (wees voorzichtig, Repchik :)).

REST-API

REST API is de ideologie van de post zwermen API, wat staat voorRepresentatieve staatsoverdracht API. Het is gebaseerd op de volgende principes, geformuleerd door de maker ervan , Roy Velding:

1. Client-server-architectuur
2. Staatloze server
3. Cachebaarheid
4. Meerlaagse structuur
5. Uniforme interface
6. Code op aanvraag

Ik zal niet in details treden, maar ik kan degenen die over dit onderwerp willen lezen adviseren

De API definieert de functionaliteit die een programma (module, bibliotheek) biedt, terwijl je met de API kunt abstraheren hoe deze functionaliteit precies wordt geïmplementeerd.

Als een programma (module, bibliotheek) als een zwarte doos wordt beschouwd, dan is de API een set “knoppen” die beschikbaar zijn voor de gebruiker van deze doos, waaraan hij kan draaien en trekken.

Softwarecomponenten communiceren met elkaar via API's. In dit geval vormen componenten gewoonlijk een hiërarchie: componenten op hoog niveau gebruiken de API van componenten op laag niveau, en zij gebruiken op hun beurt de API van componenten op nog lager niveau.

Protocollen voor gegevensoverdracht zijn op dit principe gebouwd. Het standaard internetprotocol (OSI-netwerkmodel) bevat 7 lagen (van de fysieke laag van het verzenden van bitpakketten tot de laag van applicatieprotocollen zoals HTTP- en IMAP-protocollen). Elke laag gebruikt de functionaliteit van de vorige laag voor gegevensoverdracht en levert op zijn beurt de noodzakelijke functionaliteit aan de volgende laag.

Het is belangrijk op te merken dat het concept van een protocol qua betekenis dicht bij het concept van een API ligt. Beide zijn abstracties van functionaliteit, alleen in het eerste geval hebben we het over gegevensoverdracht en in het tweede geval over het bouwen van computerapplicaties.

De functie- en klassenbibliotheek-API bevat een beschrijving handtekeningen En semantiek van functies.

Application Programming Interface (API) is een software-interface voor interactie tussen systemen, waardoor:

• Krijg toegang tot zakelijke zakelijke services
• Wissel informatie uit tussen systemen en applicaties
• Vereenvoudig de interacties tussen bedrijven, partners, ontwikkelaars en klanten

Open API-strategie

API-strategie omvat:

• Ontwikkeling van zakelijke producten op basis van bestaande API's
• Het leveren van interne diensten aan ontwikkelaars
• API-modellen voor het genereren van inkomsten voor het opbouwen van interactie via meerdere kanalen en het verhogen van de winst

De implementatie van het Open API-concept helpt bedrijven te transformeren, te integreren in een flexibel projectecosysteem van marktspelers, voorwaarden te scheppen voor de constante generatie van nieuwe ideeën en het creëren van extra waarde bij het beheren van reeksen bedrijfsgegevens.

De markt voor integratieoplossingen ontwikkelt zich in de context van de evolutie van API's - van EDI en SOAP naar Web 2.0, waarmee het tijdperk van publieke API's begon. Het aantal van dergelijke interfaces kan de komende drie jaar meer dan vijftig keer toenemen en oplopen tot één miljoen. Dit komt door omnichannel: de kanalen voor interactie met klanten moeten mee veranderen. De aanhoudende groei van het aantal consumenten en de hoeveelheid data heeft geleid tot de opkomst van de API-economie, die helpt bij het creëren van innovatieve bedrijfsmodellen voor het gebruik van bedrijfsmiddelen en -diensten op basis van open interfaces.

Functie handtekening

Functie handtekening- onderdeel van een algemene functieverklaring waarmee omroeporganisaties onder andere de functie kunnen identificeren. Verschillende programmeertalen hebben verschillende ideeën over de handtekening van een functie, wat ook nauw samenhangt met de functionaliteit van functieoverbelasting in deze talen.

Soms maken ze onderscheid handtekening bellen En handtekening van de uitvoering functies. Een oproephandtekening wordt gewoonlijk samengesteld uit de syntactische structuur van een functieaanroep, waarbij rekening wordt gehouden met de handtekening van de reikwijdte van de gegeven functie, de naam van de functie, de volgorde van de werkelijke typen argumenten in de aanroep en het type van de oproep. resultaat. De implementatiehandtekening bevat doorgaans enkele elementen uit de syntactische structuur van de functiedeclaratie: een functiescope-specificatie, de naam ervan en een reeks formele argumenttypen.

In de programmeertaal C++ wordt een eenvoudige functie bijvoorbeeld op unieke wijze door de compiler geïdentificeerd aan de hand van zijn naam en de reeks typen argumenten, die in deze taal de functiesignatuur vormt. Als een functie een methode is van een bepaalde klasse, dan wordt de klassenaam ook in de handtekening opgenomen.

Ook moet worden opgemerkt dat de programmeur vaak over meerdere verschillende API's beschikt om hetzelfde resultaat te bereiken. Bovendien wordt elke API doorgaans geïmplementeerd met behulp van API-softwarecomponenten van een lager abstractieniveau.

Bijvoorbeeld: om de regel “Hallo wereld!” in de browser te zien. U hoeft alleen maar een HTML-document te maken met een minimale titel en een eenvoudige hoofdtekst die deze regel bevat. Wat gebeurt er als de browser dit document opent? Het browserprogramma zal de bestandsnaam (of een reeds geopende bestandsdescriptor) doorgeven aan de bibliotheek die HTML-documenten verwerkt, die op zijn beurt, met behulp van de API van het besturingssysteem, dit bestand zal lezen en de structuur ervan zal begrijpen, door bewerkingen aan te roepen als “clear the window”, “schrijf Hallo wereld in het geselecteerde lettertype!”, Tijdens deze bewerkingen zal de bibliotheek met grafische primitieven contact opnemen met de vensterinterfacebibliotheek met de bijbehorende verzoeken, en deze bibliotheek zal contact opnemen met de API van het besturingssysteem met verzoeken als “plaats het in mijn videokaart buffert dit."

Bovendien zijn er op vrijwel elk niveau feitelijk meerdere mogelijke alternatieve API’s. We kunnen het brondocument bijvoorbeeld niet in HTML schrijven, maar in LaTeX, en we kunnen elke browser gebruiken voor weergave. Verschillende browsers gebruiken over het algemeen verschillende HTML-bibliotheken, en bovendien kan het geheel (in het algemeen gesproken) worden gecompileerd met behulp van verschillende primitieve bibliotheken en op verschillende besturingssystemen.

De belangrijkste uitdagingen van bestaande multi-level API-systemen zijn daarom:

• Moeilijkheden bij het overbrengen van programmacode van het ene API-systeem naar het andere (bijvoorbeeld bij het wijzigen van het besturingssysteem);
• Verlies van functionaliteit bij het overstappen van een lager niveau naar een hoger niveau. Grof gezegd wordt elke API-laag gemaakt om de uitvoering van een standaardreeks bewerkingen te vergemakkelijken. Maar tegelijkertijd wordt het erg moeilijk of fundamenteel onmogelijk om andere bewerkingen uit te voeren die door een lager API-niveau worden geleverd.

Basis API-typen

Interne API's

• API-toegang is uitsluitend beperkt tot interne ontwikkelaars
• Toepassingen zijn gericht op werknemers van ondernemingen

Zakelijke drijfveren:

• Consistentie van de ontwikkeling
• Kostenreductie
• Verhoogde ontwikkelingsefficiëntie

Partner-API's

• API's zijn alleen beschikbaar voor een beperkt aantal zakenpartners
• Applicaties zijn ontworpen voor eindgebruikers en zakelijke gebruikers

Zakelijke drijfveren:

• Automatisering van het ontwikkelingsproces
• Ontwikkeling van partnerschappen
• Optimaliseren van het proces van interactie met partners

Openbare API's

Toegang wordt verleend aan iedere externe ontwikkelaar. Applicaties zijn gericht op eindgebruikers

Zakelijke drijfveren:

• Ontwikkeling van nieuwe diensten
• Ontwikkeling van het ecosysteem
• Omnichannel-interactie

Meest bekende API's

Besturingssystemen-API

GUI-API

• Direct3D (onderdeel van DirectX)
• DirectDraw (onderdeel van DirectX)

Om het werk van hun collega's gemakkelijker te maken en alle Windows-programma's van een universele interface te voorzien, hebben Microsoft-programmeurs zoiets als een API gemaakt - "Application Programming Interface".

Dit is een reeks functies en procedures die het vaakst door programma's kunnen worden gebruikt: het weergeven van een directorystructuur, het zoeken naar bestanden, het weergeven van een standaardvenster met knoppen voor sluiten, minimaliseren en maximaliseren, en vele andere. Als gevolg hiervan hoeft een ontwikkelaar die een programma voor Windows maakt niet na te denken en speciale subroutines te ontwikkelen voor het weergeven van het programmavenster, het venster voor het selecteren van een map en andere soortgelijke elementaire bewerkingen - hij hoeft alleen maar kernel32.dll of user32 aan te roepen. dll uit de bibliotheken met functies en procedures API, de functie die hij nodig heeft, en zij zal alles voor hem zelf doen. Er zijn veel van dergelijke functies en procedures - ongeveer 600.

In het MS-DOS-besturingssysteem bestond niet zoiets als een API - degene die zich ertoe verplichtte een programma voor dit besturingssysteem te schrijven, moest nadenken en methoden implementeren voor het weergeven van afbeeldingen op het scherm, het ontvangen van gegevens van de gebruiker, van begin tot eind door het bestandssysteem reizen, afbeeldingen tekenen, als een dergelijke mogelijkheid nodig was 2. Dit maakte het proces van het ontwikkelen van programma's met een gebruiksvriendelijke interface tot een zeer arbeidsintensief proces. Vaak overtroffen de tijd en moeite die werd besteed aan het creëren van een acceptabele grafische interface voor het programma de kosten van het implementeren van het eigen algoritme van het programma, waarvoor het was gemaakt; . Het is niet voor niets dat zogenaamde "console" -applicaties heel gebruikelijk waren, dat wil zeggen programma's die alleen vanaf de opdrachtregel werkten, zonder interface - gegevens werden ingevoerd op dezelfde opdrachtregel of gemaakt vanuit een daarin gespecificeerd bestand, en de resultaten werden uitgevoerd in de eenvoudige tekstmodus.

Met de komst van het Windows-besturingssysteem werd het harde werk van programmeurs om het uiterlijk van het programma en de handige methoden voor het invoeren en verlaten van informatie te ontwikkelen aanzienlijk vergemakkelijkt - API-functies werden al gebruikt in Windows 3.0. Als de programmeur bijvoorbeeld een tekstinvoervenster of een schuifbalk wilde maken, hoefde hij alleen maar een aanroep naar de functie te schrijven om zo'n venster weer te geven met de parameters die hij nodig had, net als elke andere functie van de taal waarin hij zijn programma schreef, en niet om enorme hoeveelheden code te introduceren om een ​​programma te creëren dat zo’n venster of balk opnieuw tekent (terwijl hij zich ervan bewust is dat hij bij het ontwikkelen van het volgende programma dat ook dergelijke objecten gebruikt, zal moeten ontwikkelen dergelijke code opnieuw of probeer de oude gedeeltelijk te gebruiken en deze aan te passen aan de behoeften van dit nieuwe programma). Daarom zorgde de opkomst van de API voor een revolutionaire doorbraak in de programmeertechnologie, waardoor je veel sneller de benodigde programma's met een vertrouwde, handige interface kunt maken, zonder je zorgen te hoeven maken over routinematige details zoals het programmeren van standaardinterfaceobjecten voor de invoer en uitvoer van informatie.

In de Visual Basic for Applications (VBA)-taal worden veel API-functies en -procedures zelf aangeroepen wanneer het programma door de tolk wordt uitgevoerd, dus het is absoluut niet nodig om ze te gebruiken om tekstinvoer- en uitvoervensters weer te geven, geometrische vormen op het scherm te tekenen. scherm en andere eenvoudige acties - VBA roept ze op als dat nodig is, en het programma erop hoeft alleen de juiste functies van deze taal te gebruiken. Soms is er echter behoefte aan bepaalde acties waarvoor er ofwel geen analogen zijn in de ingebouwde VBA-functies, ofwel irrationeel of te langzaam werken. Bijvoorbeeld een mapselectievenster met een afbeelding van een mappenboom (Fig. 5.1) of een bestandzoekprogramma (analoog in VBA-functies - het object "Application.FileSearch" - werkt te langzaam met grote aantallen bestanden). Voor dergelijke gevallen biedt VBA de mogelijkheid om API-functies aan te roepen.

Helaas is het gebruik van API-functies in VBA niet gedocumenteerd in de help, dus om te leren hoe u ze kunt gebruiken, moet u zoeken naar boeken of online bronnen over kantoorprogrammering, of de code analyseren van programma's die aanroepen naar API-functies bevatten.

In de overgrote meerderheid van de gevallen kunt u bij het programmeren voor Office het doen zonder de API te gebruiken, maar soms kan het aanroepen van een API-functie al het gewenste resultaat opleveren. Stel dat u ervoor moet zorgen dat verschillende macro's worden aangeroepen wanneer u eenvoudigweg met de muis op een knop op een Word-werkbalk klikt en wanneer u tegelijkertijd op deze knop en de Shift- of Control-toets drukt. Hier is een codefragment dat dit doet:

Declareer functie GetAsyncKeyState Lib "user32.dll" (ByVal kState zo lang) als geheel getal

GetAsyncKeyState(vbKeyShift of vbKeyControl)

Als GetAsyncKeyState(vbKeyShift) Dan

Macro1 oproepen: Sub afsluiten

ElseIf GetAsyncKeyState(vbKeyControl) Then

Macro2 oproepen: Sub afsluiten

De eerste regel lijkt op het "reserveren" van een API-functie voor gebruik in een VBA-programma. Het is duidelijk dat de GetAsyncKeyState-functie wordt aangeroepen vanuit de bibliotheek (een bestand met programma's die alleen bedoeld zijn voor gebruik door andere programma's) user32.dll, en het sleutelnummer wordt doorgegeven aan deze functie, en het retourneert een geheel getal (namelijk 0, als de toets met het corresponderende nummer wordt niet ingedrukt, en -32767 of 1 indien ingedrukt). Elke functie of procedure die vanuit niet-VBA-bibliotheken wordt aangeroepen, moet op deze manier worden gereserveerd met behulp van de opdracht Declare.

De zinsnede vbKeyShift in de opdracht is een vervanging voor de Shift-toetscode (de waarde is 16), en vbKeyControl is, zoals gemakkelijk te begrijpen is, een vervanging voor de Control-toetscode. De structuur van de "If...Then"-instructies lijkt duidelijk 3, maar als dat niet het geval is, kijk dan in de VBA-help. De opdracht Aanroepen vóór de macronaam betekent, zoals u zich herinnert, dat deze wordt gestart.

Er zijn Russische sites op internet gewijd aan API 4. Bezoek ze voor meer informatie over deze functieset.