Alkalmazásprogramozási felület (API)

+++ term = “Mi az alkalmazásprogramozási felület (API)?” lastmod = “2026-10-08” title = “Mi az alkalmazásprogramozási felület (API)?” keywords = [ “alkalmazásprogramozási felület”, “alkalmazásprogramozás”, “programozási felület”, “programozás”, “api”, “alkalmazás”, “felület”, “alkalmazásprogramok” ] url = “/affiliate-marketing-szojegyzek/api/” aliases = [ “/affiliate-marketing-glossary/api/” ] description = “Az API egy szerződés, amely lehetővé teszi, hogy szoftveralkalmazások kéréseket indítsanak és adatot cseréljenek egymással.” date = “2024-11-07T10:50:18+00:00” image = "" shortDescription = “Az alkalmazásprogramozási felület (API) egy meghatározott szerződés két szoftverkomponens között, amely meghatározza, hogyan kommunikálnak egymással.” tags = [ “API”, “SoftwareDevelopment”, “Programming”, “Integration”, “Technology” ] categories = [ “Glossary” ] showCTA = true ctaHeading = “Fedezd fel a további affiliate marketing kifejezéseket” ctaDescription = “Mélyítsd el az affiliate marketinggel kapcsolatos ismereteidet az iparág alapkifejezéseit tartalmazó átfogó szószedetünkkel.” ctaPrimaryText = “Szószedet megtekintése” ctaPrimaryURL = “/affiliate-marketing-glossary/” ctaSecondaryText = “Tudj meg többet az API-król” ctaSecondaryURL = “https://en.wikipedia.org/wiki/API"

[[faq]] question = “Hogyan szerezzek be egy API-t?” answer = “Az API-hoz való hozzáférés jellemzően a következő lépéseket foglalja magában:

1. Látogass el a szolgáltató fejlesztői portáljára (például a developers.google.com, a platform.openai.com vagy az affiliate platform API-dokumentációs oldala).
2. Hozz létre egy fejlesztői fiókot.
3. Regisztrálj egy alkalmazást vagy projektet — ez mondja meg a szolgáltatónak, hogy ki küldi a kéréseket.
4. Hozd létre a hitelesítő adatokat: egy API-kulcsot, egy kliensazonosító/titkos kulcs párost vagy egy OAuth-tokent.
5. Olvasd el a dokumentációt, hogy megértsd az elérhető végpontokat, a kérésformátumokat, a sebességkorlátokat és a hibakezelést.
6. Küldd el az első tesztkérést — gyakran sandbox- vagy tesztkörnyezetben, mielőtt élesben használnád.”

[[faq]] question = “Mi az az API egyszerűen fogalmazva?” answer = “Az API egy hírvivő. Az egyik program meghatározott formátumban tesz fel egy kérdést; a másik program válaszol. Nem kell tudnod, hogyan működik a válaszoló program belülről — csak azt kell tudnod, milyen kérdéseket tehetsz fel, és milyen formátumban érkezik a válasz. A vendéglős hasonlat: az étlap az API-dokumentáció, a felszolgáló az API, a konyha pedig a háttérrendszer. Az étlapról rendelsz; a felszolgáló továbbítja a kérésed a konyhának, és visszahozza az ételt.”

[[faq]] question = “Mi az a webes API?” answer = “A webes API egy olyan API, amely az interneten keresztül, HTTP (vagy HTTPS) segítségével kommunikál. Ma ez a leggyakoribb API-típus. Amikor egy mobilalkalmazás adatokat tölt le egy szerverről, amikor egy weboldal Google Térképet ágyaz be, vagy amikor egy affiliate platform konverziót rögzít egy e-kereskedelmi áruházból — egy webes API bonyolítja le az adatcserét. A webes API-k a távoli (remote) API-k egy részhalmazát képezik, amelyek közé olyan protokollok is tartoznak, mint az RPC és a WebSocket, amelyek használhatnak HTTP-t, de nem feltétlenül.”

[[faq]] question = “Mik azok az API-integrációk?” answer = “Az API-integrációk azok a kapcsolatok, amelyeket két vagy több rendszer között építenek ki az API-ik segítségével. Meghatározzák, hogy milyen adat mozog, milyen irányban, milyen esemény hatására, és hogyan történik a hibakezelés. Egy e-kereskedelmi platform és egy affiliate-követő rendszer közötti integráció — ahol egy teljesített vásárlás automatikusan konverziós adatokat küld a követő API-nak — klasszikus példa.”

[[faq]] question = “A ChatGPT API?” answer = “Igen. Az OpenAI nyilvános webes API-n keresztül teszi elérhetővé a ChatGPT-modelleket. A fejlesztők JSON-adattartalomként küldik a promptokat olyan végpontokra, mint a https://api.openai.com/v1/chat/completions , és a válaszban generált szöveget kapnak. Ugyanez az API-modell érvényes: hitelesítés, strukturált kérés küldése, strukturált válasz fogadása. Az árazás tokenenként történik (nagyjából ~750 szavanként), eltérő díjakkal a bemeneti és kimeneti tokenekre, valamint a különböző modellszintekre.”

[[faq]] question = “Mi az a REST API?” answer = “A REST (Representational State Transfer) egy architekturális stílus webes API-khoz. A REST API-k az adatentitásokat erőforrásként kezelik, amelyek kiszámítható URL-eken érhetők el, és szabványos HTTP-metódusokkal manipulálhatók: GET (olvasás), POST (létrehozás), PUT (frissítés), DELETE (törlés). Állapotmentesek — minden kérés tartalmazza mindazt az információt, amire a szervernek szüksége van, és a szerver oldalán nem tárolódik munkamenet.”

[[faq]] question = “Hogyan védjünk le egy REST API-t?” answer = “A következő intézkedésekkel védheted le a REST API-t: (1) mindig HTTPS-t használj — soha ne nyers HTTP-t; (2) minden kérésnél követelj meg hitelesítést API-kulcsok, OAuth 2.0-tokenek vagy JWT segítségével; (3) vezess be hatókörökre bontott jogosultságkezelést, hogy minden kliens csak a saját adataihoz férhessen hozzá; (4) ellenőrizd és tisztítsd meg az összes bemenetet az injekciós támadások megelőzésére; (5) alkalmazz sebességkorlátot a visszaélések megelőzésére; (6) naplózd az összes kérést, és figyeld a rendellenességeket; (7) tartsd frissen a függőségeket és a szerver szoftverét; (8) helyezd üzembe egy API Gateway mögött, amely központosítja a biztonsági szabályok érvényesítését.”

[[faq]] question = “Mi az az API Gateway?” answer = “Az API Gateway egy olyan szerver, amely az API-forgalom egyetlen belépési pontjaként működik. A bejövő kéréseket a megfelelő háttérszolgáltatáshoz továbbítja, érvényesíti a hitelesítést és a sebességkorlátokat, szükség esetén átalakítja a kéréseket és a válaszokat, gyorsítótárazza a gyakori lekérdezéseket, és naplózza az összes forgalmat. Minden olyan platform számára, amely több klienst kiszolgál vagy mikroszolgáltatás-alapú architektúrát futtat, az API Gateway alapinfrastruktúra — leegyszerűsíti a klienskapcsolatokat és erősíti a biztonságot.”

[[faq]] question = “Mi a különbség a SOAP és a REST között?” answer = “A SOAP protokoll; a REST architekturális stílus. A SOAP-üzenetek mindig XML-formátumúak, és a WSDL-fájl által meghatározott szigorú szerkezetet követik. A REST-válaszok jellemzően JSON-formátumúak (bár az XML is lehetséges), és lazább konvenciókat követnek. A SOAP beépített szabványokkal rendelkezik a biztonság, a tranzakciók és a megbízhatóság terén (WS-*), ami alkalmassá teszi vállalati környezetekre, például a banki szektorra. A REST egyszerűbb, gyorsabban bevezethető, és az új API-fejlesztésekben dominál.”

[[faq]] question = “Mi az a GraphQL?” answer = “A GraphQL egy lekérdezési nyelv API-khoz, amelyet a Facebook (Meta) fejlesztett ki. A REST-tel ellentétben — ahol a szerver határozza meg a rögzített végpontokat és a rögzített válaszformákat — a GraphQL lehetővé teszi, hogy a kliens pontosan megadja, mely mezőkre van szüksége. Ez megoldja a túllekérdezést (over-fetching) és az alullekérdezést (under-fetching) — a kliens pontosan azt az adatot kapja, amit kért, se többet, se kevesebbet. A GraphQL különösen hasznos mobilalkalmazásokhoz és összetett adatmodellekhez, de kifinomultabb szerveroldali megvalósítást és gyorsítótárazási stratégiákat igényel.”

[[faq]] question = “Hogyan teszteljek egy API-t?” answer = “Az API-tesztelés ellenőrzi, hogy az API érvényes és érvénytelen bemenetekre is a várt válaszokat adja-e. Kezdd kézi felfedezéssel egy olyan eszközzel, mint a Postman, vagy egy egyszerű curl paranccsal. Ezután építs automatizált tesztsorozatokat: funkcionális teszteket, amelyek minden végpont sikeres (happy path) és hibás eseteit ellenőrzik; szerződéses teszteket, amelyek a válaszkémákat az OpenAPI-specifikációval vetik össze; és terheléses teszteket, amelyek egyidejű kérések mellett mérik a teljesítményt. Futtasd az automatizált teszteket a CI/CD-rendszerben minden kódváltozásnál.”

[[faq]] question = “Mi az az API-hívás?” answer = “Az API-hívás egyetlen kérés, amelyet egy kliensalkalmazás küld egy API-végpontnak, választ várva. HTTP-metódusból, URL-ből, opcionális fejlécekből és opcionális törzsből áll. A szerver feldolgozza a kérést, és visszaad egy státuszkódot és — általában — egy választörzset. Valahányszor egy időjárás-alkalmazás ellenőrzi az előrejelzést, egy fizetési oldal megerősít egy tranzakciót, vagy egy affiliate-irányítópult frissíti a jutalékadatokat, egy vagy több API-hívás zajlik a háttérben.”

[[faq]] question = “Hol találok új API-kat?” answer = “A nyilvános API-katalógusok, mint a RapidAPI, a ProgrammableWeb és a Postman API Network, több ezer API-t sorolnak fel különböző kategóriákban. Affiliate marketinghez kapcsolódó API-khoz kezdd a platformod fejlesztői portálján — a legtöbb affiliate SaaS-szolgáltató nyilvánosan dokumentálja az API-it. Kormányzati szervek (data.gov, weather.gov), közösségi platformok (Meta, X, LinkedIn) és fizetésfeldolgozók (Stripe, PayPal) mind működtetnek fejlesztői portálokat API-dokumentációval és bevezető útmutatókkal.”

[[faq]] question = “Hogyan írjak API-dokumentációt?” answer = “A jó API-dokumentáció egy OpenAPI-specifikációval kezdődik — minden végpont, paraméter, válasz és hiba géppel olvasható leírásával. Ebből a specifikációból az olyan eszközök, mint a Swagger UI és a Redoc, interaktív referencia-dokumentációt generálnak. A referenciaanyagon túl foglald bele: a hitelesítési útmutatót (hogyan szerezd meg és használd a hitelesítő adatokat), egy gyorsindító oktatóanyagot (a lehető legegyszerűbb működő példát), kódmintákat több programozási nyelven, és egy változásnaplót. A dokumentáció nem egyszeri feladat; naprakészen kell tartani az API-val, ahogy a végpontok és a viselkedések változnak.

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "A ChatGPT API?", "acceptedAnswer": { "@type": "Answer", "text": "Igen. Az OpenAI nyilvános webes API-n keresztül teszi elérhetővé a ChatGPT-modelleket. A fejlesztők JSON-adattartalomként küldik a promptokat, és válaszként generált szöveget kapnak. Az árazás tokenenként történik, eltérő díjakkal a bemeneti és kimeneti tokenekre, valamint a különböző modellszintekre. } }, { "@type": "Question", "name": "Hogyan szerezzek be egy API-t?", "acceptedAnswer": { "@type": "Answer", } }, { "@type": "Question", "name": "Mi az az API egyszerűen fogalmazva?", "acceptedAnswer": { "@type": "Answer", "text": "Az API hírvivő a szoftverprogramok között. Az egyik program meghatározott formátumban tesz fel egy kérdést; a másik válaszol. A vendéglős hasonlat: az étlap az API-dokumentáció, a felszolgáló az API, a konyha pedig a háttérrendszer." } }, { "@type": "Question", "name": "Mi az a webes API?", "acceptedAnswer": { "@type": "Answer", "text": "A webes API HTTP vagy HTTPS segítségével kommunikál az interneten keresztül. Amikor egy mobilalkalmazás adatokat tölt le, egy weboldal Google Térképet ágyaz be, vagy egy affiliate platform konverziót rögzít egy e-kereskedelmi áruházból, egy webes API bonyolítja le az adatcserét." } }, { "@type": "Question", "name": "Mi az a REST API?", "acceptedAnswer": { "@type": "Answer", "text": "A REST (Representational State Transfer) egy architekturális stílus webes API-khoz. A REST API-k az adatentitásokat erőforrásként kezelik kiszámítható URL-eken, és szabványos HTTP-metódusokat használnak: GET (olvasás), POST (létrehozás), PUT (frissítés), DELETE (törlés). Állapotmentesek, és ez a legszélesebb körben használt API-stílus." } }, { "@type": "Question", "name": "Hogyan védjünk le egy REST API-t?", "acceptedAnswer": { "@type": "Answer", } }, { "@type": "Question", "name": "Mi az az API Gateway?", "acceptedAnswer": { "@type": "Answer", "text": "Az API Gateway egy olyan szerver, amely az API-forgalom egyetlen belépési pontjaként működik. A kéréseket a megfelelő háttérrendszerhez továbbítja, érvényesíti a hitelesítést és a sebességkorlátokat, átalakítja a kéréseket és a válaszokat, gyorsítótárazza a lekérdezéseket, és naplózza az összes forgalmat." } }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "A SOAP szigorú, WSDL-fájlok által meghatározott XML-üzeneteket használó protokoll. A REST architekturális stílus, amely jellemzően JSON-t használ lazább konvenciókkal. A SOAP beépített biztonsági és tranzakciós szabványokkal rendelkezik, amelyek vállalati környezetekhez illenek. A REST egyszerűbb, és az új API-fejlesztésekben dominál." } }, { "@type": "Question", "name": "Mi az a GraphQL?", "acceptedAnswer": { "@type": "Answer", "text": "A GraphQL egy lekérdezési nyelv API-khoz, amelyet a Meta fejlesztett ki. A REST rögzített végpontjaival ellentétben a GraphQL lehetővé teszi, hogy a kliens pontosan megadja, mely mezőkre van szüksége, megoldva a túllekérdezés és az alullekérdezés problémáját. Hasznos mobilalkalmazásokhoz és összetett adatmodellekhez." } }, { "@type": "Question", "name": "Mi az az API-hívás?", "acceptedAnswer": { "@type": "Answer", "text": "Az API-hívás egyetlen kérés, amelyet egy kliensalkalmazás küld egy API-végpontnak; HTTP-metódusból, URL-ből, opcionális fejlécből és opcionális törzsből áll. A szerver visszaad egy státuszkódot és egy választörzset." } } ] } </script>” +++ For browser-side integrations, MDN’s Web API reference documents the interfaces available to website code. These differ from an affiliate platform’s own API, whose authentication, endpoints, and limits must be checked in that platform’s documentation.

Mi az API (Alkalmazásprogramozási felület)?

Egy alkalmazásprogramozási felület (API) egy meghatározott szerződés két szoftverkomponens között, amely meghatározza, hogyan kommunikálnak. Az egyik komponens strukturált formátumban kérést küld; a másik a kért adatokkal válaszol, vagy végrehajtja a kért műveletet.

A definíciónak három fontos része van:

1. Alkalmazás (Application) — bármely, egyértelmű funkcióval rendelkező szoftver, a mobil időjárás-alkalmazástól a fizetési átjárón át az affiliate-követő platformig.
2. Programozás (Programming) — a fejlesztők kódon keresztül használják az API-t, nem grafikus felhasználói felületen keresztül. Az API konkrét függvényeket, végpontokat vagy metódusokat tesz elérhetővé, amelyeket meghívhatnak.
3. Felület (Interface) — a határréteg. Csak azt mutatja, amire a fejlesztőnek szüksége van — az elérhető műveletek menüjét —, és minden mást elrejt: az adatbázis-sémát, a szerverinfrastruktúrát, a belső üzleti logikát.

Kritikus szempont, hogy az API nem felhasználói felület. A végfelhasználók soha nem látják. Amikor egy vásárló egy e-kereskedelmi oldalon rákattint a “Pay with PayPal” gombra, és másodpercekkel később megerősítő képernyőt lát, az API bonyolította le az áruház és a PayPal szerverei közötti kapcsolatfelvételt — a vásárló azonban csak az eredményt látta.

Indítsd el affiliate programodat még ma

Állítsd be a fejlett nyomkövetést percek alatt. Bankkártya nem szükséges.

Demó kérése 30 napos ingyenes próba indítása

Mit jelent az API rövidítés?

Az API az Application Programming Interface (alkalmazásprogramozási felület) rövidítése. Bontsuk szét:

A kifejezés legalább az 1960-as évek óta használatban van, de a 2000-es évek elején a webes API-k térnyerésével került be a mainstream szoftveres szókincsbe. Ma, amikor a legtöbben különösebb pontosítás nélkül mondják, hogy “API”, egy webes API-ra gondolnak — olyanra, amely HTTP-n keresztül kommunikál az interneten.

Hogyan működnek az API-k?

Az API-kommunikáció egy kliens–szerver kérés–válasz modellt követ. Íme egyetlen API-hívás életciklusa:

1. A kliensalkalmazás kérést indít. A fejlesztő kódot ír, amely HTTP-kérést küld egy adott API-végpontra — egy URL-re, amely egy erőforrást vagy műveletet képvisel. A kérés metódust (GET, POST, PUT, DELETE), fejléceket (metaadatokat, például hitelesítési tokeneket), és opcionálisan törzset (az adattartalmat, gyakran JSON-formátumban) tartalmaz.

2. Az API fogadja és érvényesíti a kérést. A szerver ellenőrzi, hogy a kérés jól formázott-e, a hitelesítési adatok érvényesek-e, és hogy a kliens jogosult-e a kért művelet végrehajtására.

3. A szerver feldolgozza a kérést. Ez magában foglalhat adatbázis-lekérdezést, egy másik belső szolgáltatás hívását, adatátalakítást vagy üzleti folyamat elindítását. Az API-réteg mindezt elrejti a kliens elől.

4. A szerver választ küld vissza. A válasz HTTP-státuszkódot (200 sikeres, 404 nem található, 500 szerverhiba stb.), válaszfejléceket, és jellemzően a kért adatokat vagy megerősítő üzenetet tartalmazó törzset — gyakran JSON vagy XML formátumban — tartalmaz.

5. A kliensalkalmazás feldolgozza a választ. A hívó kód elemzi az adatokat, és felhasználja őket — frissít egy megjelenítést, eltárol egy rekordot, elindítja a munkafolyamat következő lépését.

Egy konkrét példa: a telefonod időjárás-alkalmazása egy GET /weather?city=Dallas jellegű kérést küld egy időjárás-szolgáltató API-nak. Az API lekérdezi az adatforrásait, JSON-választ állít össze a hőmérséklettel, a páratartalommal és az előrejelzéssel, majd visszaküldi. Az alkalmazás elemzi a JSON-t, és megjeleníti: “82°F, részben felhős.” Az alkalmazásnak soha nem kell tudnia, hogy az időjárás-szolgáltató hogyan gyűjti vagy tárolja az adatait — csak az API szerződését kell követnie.

Az API-hívás lépésről lépésre

• Végpont (Endpoint): Az URL, ahol az API él — pl. https://api.weatherservice.com/v2/weather
• Metódus (Method): A HTTP-ige — GET (olvasás), POST (létrehozás), PUT (frissítés), DELETE (törlés)
• Fejlécek (Headers): Metaadatok — tartalomtípus, hitelesítési token, API-kulcs
• Paraméterek (Parameters): Lekérdezési sztringértékek vagy útváltozók, amelyek finomítják a kérést — ?city=Dallas&units=imperial
• Törzs (Body): A POST vagy PUT kérésekkel küldött adattartalom, jellemzően JSON
• Válasz (Response): Státuszkód + fejlécek + törzs (az adat, egy hibaüzenet, vagy mindkettő)

Iratkozz fel hírlevelünkre

Értesülj elsőként az új funkciókról és termékfrissítésekről.

E-mail cím

Feliratkozás

Mi az API-végpont, és miért fontos?

Az API-végpont egy adott URL (vagy URI) az API-n belül, amely egy adott erőforrásnak vagy műveletnek felel meg. Míg az API a teljes felület, a végpont egy címezhető érintkezési pont rajta belül.

Például egy hipotetikus affiliate marketing API a következő végpontokat teheti elérhetővé:

Minden végpont egy külön képességet képvisel. A jól megtervezett API-k következetes, kiszámítható végpontelnevezést használnak, így a fejlesztők a dokumentáció állandó böngészése nélkül is átláthatják a felületet. Ez a minta — az URL-ek erőforrásként való kezelése és a HTTP-metódusok használata a műveletek leírására — a REST API-tervezés alapja.

A végpontok azért fontosak, mert meghatározzák annak finomságát, hogy mit kérhetsz a rendszertől. A jól megtervezett végpontokkal rendelkező API lehetővé teszi a fejlesztőknek, hogy összetett munkafolyamatokat építsenek egyszerű, újrafelhasználható hívásokból. A rosszul megtervezett végpontokkal rendelkező API megkerülő megoldásokra kényszeríti a fejlesztőket — több hívást kell leadniuk, hogy összeállítsák azokat az adatokat, amelyeknek egyetlen hívásban kellene rendelkezésre állniuk, vagy óriási válaszokat kell elemezniük, hogy megtalálják az egyetlen szükséges mezőt.

Milyen API-típusok léteznek?

Az API-k kétféleképpen kategorizálhatók: hozzáférési szint (ki használhatja őket) és technikai réteg (hol működnek a szoftververemben) szerint.

API-típusok hozzáférési szint szerint

A nyilvános API-k — más néven nyílt API-k — a leglátványosabb kategória. Az olyan vállalatok, mint a Google (Térkép), a Stripe (fizetések) és az OpenAI (ChatGPT), nyilvános API-kat tesznek elérhetővé, amelyeket bármely fejlesztő integrálhat a hitelesítő adatok regisztrálása után. Az üzleti modell változó: egyesek díjmentesek sebességkorlátokkal, mások hívásonként számolnak fel díjat, megint mások egy platform elfogadását ösztönzik.

A partner API-k a nyilvános és a privát között helyezkednek el. Meghatározott üzleti partnerek számára teszik elérhetővé őket tárgyalásos feltételekkel. Egy affiliate hálózat például elérhetővé tehet egy partner API-t, amely lehetővé teszi az engedélyezett hirdetőknek, hogy programozott módon kérdezzenek le jutalékadatokat — ugyanez az API azonban a nagyközönség számára nem érhető el.

A privát API-k — más néven belső API-k — kizárólag egy szervezeten belül használatosak. Egy vállalat mobilalkalmazása egy privát API-n keresztül kommunikálhat a háttérrendszerével, amelyet egy nyilvános felhasználó soha nem fedezhetne fel. Ezek az API-k a belső fejlesztők termelékenységét és a biztonságot helyezik előtérbe az általános célú használhatósággal szemben.

A kompozit API-k egy teljesítményproblémát oldanak meg: ha egyetlen felhasználói művelethez öt különböző szolgáltatásból van szükség adatokra, öt külön API-hívás késleltetést ad hozzá. A kompozit API ezeket a kéréseket egyetlen hívásba fogja össze, és egységes választ ad vissza. Gyakoriak a mikroszolgáltatás-alapú architektúrákban és az API Gateway-konfigurációkban.

API-típusok technikai réteg szerint

• Hardver- és firmware-API-k lehetővé teszik, hogy a szoftver fizikai összetevőkkel — processzorokkal, érzékelőkkel, grafikus kártyákkal — kommunikáljon. Ezek a legalacsonyabb szintű felületek.
• Operációsrendszer-API-k teszik elérhetővé az operációs rendszer szolgáltatásait — fájlkezelés, folyamatütemezés, memóriafoglalás, hálózati vermek. Példa erre a Windows API, a POSIX és a Cocoa.
• Könyvtár- és keretrendszer-API-k lehetővé teszik a fejlesztőknek, hogy ugyanazon futási környezeten belül előre megírt függvényeket hívjanak. A Python-fejlesztő, aki importálja a requests modult, és meghívja a requests.get() függvényt, könyvtár-API-t használ. Nincs benne hálózati forgalom.
• Adatbázis-API-k szabványosítják az adatbázis-kezelő rendszerekkel való kommunikációt. Az ODBC, a JDBC és az olyan natív illesztőprogramok, mint a PostgreSQL-hez készült psycopg2, ebbe a kategóriába tartoznak.
• Webes API-k teszik lehetővé a különálló alkalmazások közötti kommunikációt hálózaton keresztül, jellemzően HTTP segítségével. A legtöbb ember ma erre gondol, amikor “API”-t mond, és a cikk további része is erre összpontosít.

Web API-protokollok és stílusok

Nem minden webes API épül ugyanúgy. A protokoll — amelyet néha architekturális stílusnak is neveznek — meghatározza, hogyan épülnek fel a kérések és a válaszok, milyen formátumokat használnak, és milyen megkötéseket követnek.

REST API-k (Representational State Transfer)

• Kliens–szerver szétválasztás: A kliens kezeli a felhasználói felületet; a szerver az adattárolást. Egymástól függetlenül fejlődnek.
• Állapotmentesség: A kliens minden kérésének tartalmaznia kell mindazt az információt, amelyre a szervernek a teljesítéshez szüksége van. A szerver nem tárol klienskörnyezetet a kérések között.
• Gyorsítótárazhatóság: A válaszoknak kifejezetten deklarálniuk kell, hogy gyorsítótárazhatók-e, ami javítja a teljesítményt.
• Egységes felület: Az erőforrásokat URL-ek azonosítják, reprezentációkon (JSON, XML) keresztül manipulálják őket, és szabványos HTTP-metódusokon keresztül érik el.
• Rétegzett rendszer: A kliens nem tudja megállapítani, hogy közvetlenül a végkiszolgálóhoz csatlakozik-e, vagy egy közvetítőhöz — terheléselosztóhoz, gyorsítótárhoz vagy API Gateway-hez.

A REST API-k előnyei:

• Nyelv- és platformfüggetlen — bármely HTTP-kliens hívhatja őket
• Skálázható az állapotmentességnek és a gyorsítótárazásnak köszönhetően
• Könnyen megérthető és tesztelhető — egy REST API-t akár egy böngészővel vagy curl-lel is felfedezhetsz
• Gazdag eszközökből álló ökoszisztéma: OpenAPI/Swagger a dokumentációhoz, Postman a teszteléshez, API Gateway-ek a kezeléshez

A REST korlátai:

• Túllekérdezés (over-fetching): egy végpont 20 mezőt is visszaadhat, amikor csak kettőre van szükséged
• Alullekérdezés (under-fetching): több végpontot is hívnod kell, hogy összeállítsd az egy képernyőhöz szükséges adatokat (az N+1 lekérdezési probléma)
• Nincs beépített támogatás a valós idejű frissítésekhez

SOAP API-k (Simple Object Access Protocol)

A SOAP egy régebbi, XML-alapú protokoll, amely megelőzi a REST-et. Merevebb: az üzeneteknek szigorú XML-sémának kell megfelelniük, és a protokoll a WS-* szabványokon keresztül saját biztonsági és tranzakciós szabályokat határoz meg.

A SOAP-ot ma is használják vállalati környezetekben — pénzügyi szolgáltatások, fizetésfeldolgozás és kormányzati rendszerek —, ahol a beépített biztonság, a tranzakciók integritása és a formális szerződések (WSDL-fájlok) fontosabbak, mint a REST egyszerűsége. A SOAP örökölt infrastruktúra, amely tovább él, nem pedig olyan technológia, amelyet a csapatok zöldmezős projektekhez választanának.

GraphQL

Ahelyett, hogy a szerver rögzített végpontokat és rögzített válaszformákat határozna meg, a kliens pontosan megadja egyetlen lekérdezésben, hogy mely mezőket szeretné:

query {
  affiliate(id: "4821") {
    name
    totalEarnings
    recentCommissions(limit: 5) {
      amount
      date
      campaign { name }
    }
  }
}

RPC- és WebSocket-API-k

• Távoli eljáráshívás (RPC) API-k szerveroldali műveleteket függvényhívásként kezelnek. A kliens meghívja a createInvoice(customer, amount) függvényt, és a szerver visszaadja az eredményt. A Google által fejlesztett gRPC a modern RPC-keretrendszer — Protocol Buffers-t használ a hatékony bináris szerializációhoz, és népszerű a mikroszolgáltatás-alapú architektúrákban, ahol a teljesítmény fontosabb, mint az emberi olvashatóság.

• WebSocket-API-k állandó kétirányú kapcsolatot tartanak fenn. A REST kérés–válasz modelljétől eltérően a WebSocket lehetővé teszi, hogy a szerver kérés nélkül küldjön adatot a kliensnek. Ez elengedhetetlen a valós idejű funkciókhoz: csevegőalkalmazások, élő irányítópultok, kollaboratív szerkesztés és adatfolyamok.

Mik az API-integrációk?

Az API-integráció két vagy több szoftverrendszer összekapcsolásának folyamata az API-ikon keresztül, hogy adatot cserélhessenek és műveleteket indíthassanak automatikusan. Az integráció meghatározza:

• Mely végpontokat hívják
• Mi váltja ki a hívást (ütemezett feladat, felhasználói művelet, webhook-esemény)
• Hogyan történik az adatok leképezése a két rendszer formátumai között
• Hogyan történik a hibák és az újrapróbálkozások kezelése

Például egy e-kereskedelmi platform és egy affiliate-követő rendszer közötti API-integráció így működhet: amikor egy vásárló teljesít egy vásárlást, az e-kereskedelmi platform POST-kérést küld a követő rendszer /conversions végpontjára a rendelés adataival, az affiliate-azonosítóval és a jutalékösszeggel. A követő rendszer rögzíti a konverziót, és megerősítést küld vissza. Senki sem másolt adatot táblázatok között; nem küldtek e-mailben CSV-fájlokat.

Egy átlagos középvállalat több mint 100 SaaS-alkalmazást használ, és azok, amelyek zökkenőmentesen működnek együtt — dokumentált, stabil API-kon keresztül —, azok nyernek.

Hogyan támogatják az API-k az affiliate marketinget

Az affiliate marketing adatokon alapul: kattintások, konverziók, jutalékráták, kifizetési ütemezések, teljesítménymutatók. Minden egyes adatnak megbízhatóan és közel valós időben kell mozognia a rendszerek között. Az API-k teszik ezt lehetővé.

Hirdetőknek (kereskedőknek)

A hirdetők API-kat használnak az alábbiakra:

• Konverziókövetés automatizálása. Amikor egy eladás megtörténik, az e-kereskedelmi platform meghívja az affiliate platform API-ját a konverzió rögzítéséhez, a megfelelő affiliate-nek való hozzárendeléséhez és a jutalék kiszámításához — mindezt ezredmásodpercek alatt.
• Termékkatalógusok szinkronizálása. A termékfeedek, az árváltozások és a készletfrissítések API-hívásokon keresztül áramlanak a hirdető rendszeréből az affiliate platformra, így a kiadói listák pontosak maradnak.
• Teljesítményjelentések lekérése. Ahelyett, hogy bejelentkeznének egy irányítópultra és CSV-ket exportálnának, a hirdetők az API-t használhatják, hogy a valós idejű teljesítményadatokat saját üzleti intelligencia eszközeikbe — Tableau, Power BI vagy egyedi elemzési rendszer — vezessék.
• Affiliate-ek programozott kezelése. Alkalmazások jóváhagyása, jutalékszintek módosítása és üzenetek küldése az affiliate-eknek API-hívásokon keresztül, kézi adminisztrációs panel kattintgatás helyett.

Kiadóknak (affiliate-eknek)

A kiadók API-kat használnak az alábbiakra:

• Affiliate-linkek és kreatív anyagok dinamikus lekérése. Ahelyett, hogy linkeket másolnának egy irányítópultról, a kiadó az API-t használhatja a megfelelő követőlink lekéréséhez bármely termékhez valós időben, biztosítva, hogy a linkek soha ne szakadjanak meg, és mindig az aktuális ajánlatra mutassanak.
• Jutalékállapot ellenőrzése. A kiadók lekérdezhetik az API-ból a függőben lévő, jóváhagyott és kifizetett jutalékokat — és saját irányítópultokat vagy riasztásokat építhetnek ezekre az adatokra.
• Tartalomfrissítések automatizálása. Egy termékeket értékelő tartalmi oldal az API-t használhatja az aktuális árak és elérhetőség lekérésére, így az értékelések pontosak maradnak kézi szerkesztés nélkül.

Affiliate programmenedzsereknek

A programmenedzserek a hirdetők és a kiadók között helyezkednek el. Az API-k lehetővé teszik számukra, hogy:

• Figyeljék a program egészségét. Adatok összesítése az összes affiliate és kampány között, rendellenességek észlelése (olyan kiadó, akinek a konverziós rátája hirtelen nullára esik), és riasztások indítása.
• Automatizálják a kifizetéseket. Az affiliate platform API-jának integrálása könyvelő szoftverrel vagy fizetési átjáróval a jutalékfizetések ütemezett kötegelt feldolgozásához.
• Biztosítsák a megfelelést. Gyanús minták — kattintásözön, szokatlanul magas visszaterhelési (chargeback) arányok — lekérdezése az API-ból, és programozott intézkedés.

Megértendő korlátok

Az affiliate marketingben az API-k hatékonyak, de nem varázslatosak:

• Sebességkorlátok. A legtöbb platform korlátozza a percenkénti vagy napi kérések számát. Az a kiadó, amely 10 000 termékhez kér élő árakat óránként, elérheti ezeket a korlátokat, és szüksége lehet a válaszok helyi gyorsítótárazására.
• Késleltetés. Egy 500 ms-ot igénybe vevő API-hívás gyors az embernek, de lassú az oldalbetöltés szempontjából kritikus kéréseknél. Az API-hívásokat mindig szerveroldalon vagy aszinkron módon végezd, soha ne az oldal megjelenítésébe ágyazva.
• Verziókezelés. Az API-k változnak. A ma működő követővégpont hat hónap múlva elavult lehet. Iratkozz fel a változásnaplókra, rögzítsd az integrációidat adott API-verziókhoz, és üzembe helyezés előtt tesztelj sandbox-környezetekben.
• Hitelesítéskezelés. Az API-kulcsok és tokenek hitelesítő adatok. Elforgatásuk, biztonságos tárolásuk (soha ne kliensoldali kódban vagy nyilvános adattárakban), és a hatókörökre bontott jogosultságok kezelése folyamatos üzemeltetési felelősség — nem egyszeri beállítás.

Mi az API Gateway?

Az API Gateway egy olyan szerver, amely a kliensek és háttérszolgáltatások gyűjteménye között helyezkedik el, és minden API-kérés egyetlen belépési pontjaként működik. A kliensek ahelyett, hogy közvetlenül hívnák az egyes mikroszolgáltatásokat, az átjárót hívják, amely a kéréseket továbbítja, a szabályzatokat érvényesíti, és a válaszokat összesíti.

Az API Gateway jellemzően az alábbiakat kezeli:

• Útválasztás: A kérések irányítása a megfelelő háttérszolgáltatáshoz az URL-útvonal, a fejlécek vagy a paraméterek alapján
• Hitelesítés és jogosultságkezelés: API-kulcsok, JWT-tokenek vagy OAuth-hitelesítő adatok érvényesítése, mielőtt a kérés elérné a háttérrendszert
• Sebességkorlátozás: Kliensenkénti kéréskvóták érvényesítése a háttérszolgáltatások túlterhelés elleni védelmére
• Kérés- és válaszátalakítás: Protokollok közötti konvertálás (REST-ről gRPC-re), fejlécek hozzáadása vagy eltávolítása, adattartalmak átalakítása
• Gyorsítótárazás: Azonos kérések gyorsítótárazott válaszainak visszaadása a háttérrendszer terhelésének csökkentésére
• Naplózás és megfigyelés: Mérőszámok gyűjtése a kérésvolumenről, a késleltetésről és a hibaarányokról

Egy affiliate platform esetében az API Gateway több ezer kiadó hitelesítését kezelheti, sebességkorlátot szabhat az egyes API-kulcsokra a visszaélés megelőzése érdekében, és a különböző kéréstípusokat — követőhívások, jelentéslekérdezések, adminisztrációs parancsok — a különböző háttérszolgáltatásokhoz irányíthatja — mindezt egyetlen, egységes tartomány mögött, például az api.yourplatform.com mögött.

Nem opcionálisak egyetlen olyan platformnál sem, amely éles API-forgalmat kezel nagy mennyiségben.

API-biztonság

Az API-k üzleti logikát és adatokat tesznek ki a hálózatnak, ami nagy értékű célponttá teszi őket. Az API védelme több réteget foglal magában:

• Hitelesítés. Minden API-kérésnek igazolnia kell, hogy ki küldi. Gyakori mechanizmusok: API-kulcsok (egyszerűek, de könnyen kiszivároghatnak), OAuth 2.0-tokenek (a delegált hozzáférés iparági szabványa) és kölcsönös TLS (tanúsítványalapú, gyakori a B2B- és pénzügyi API-knál).

• Jogosultságkezelés. A hitelesítés az identitást igazolja; a jogosultságkezelés azt határozza meg, hogy az adott identitás mit tehet. Egy kiadó API-kulcsának a saját jutalékait kell lekérdezhetővé tennie — nem másokét. Vezess be hatókörökre bontott jogosultságokat, és ellenőrizd őket minden kérésnél.

• Szállítási biztonság. Mindig HTTPS-t (TLS 1.2 vagy újabb) használj. Éles környezetben soha ne tegyél ki API-végpontot nyers HTTP-n. Ez titkosítja az adatokat a továbbítás során, és megakadályozza a közbeékelődéses (man-in-the-middle) támadásokat.

• Bemenetellenőrzés. Kezelj minden API-kérést potenciálisan rosszindulatúként. Ellenőrizd az adattípusokat, a sztringhosszakat, a numerikus tartományokat és az enumerációs értékeket a feldolgozás előtt. Utasíts el minden váratlan bemenetet — ne próbáld meg “kijavítani” a hibásan formázott bemenetet.

• Sebességkorlátozás. Korládozd, hogy egy kliens egy adott időablakban hány kérést indíthat. Ez megakadályozza mind a véletlen túlterhelést, mind a szándékos denial-of-service támadásokat. Ha a korlát túllépésre kerül, küldj HTTP 429 (Too Many Requests) választ Retry-After fejléccel.

• Naplózás és megfigyelés. Naplózz minden API-kérést — időbélyeg, kliensazonosító, végpont, metódus, státuszkód és késleltetés. Figyeld a naplókat rendellenességekért: hirtelen kiugrások, szokatlan hibaminták, új IP-tartományokból érkező kérések. A biztonsági incidensek először a naplókban látszanak, nem a felhasználói bejelentésekben.

• API Gateway mint biztonsági réteg. Az API Gateway központosítja a hitelesítést, a sebességkorlátozást és a kérésellenőrzést, csökkentve az egyes háttérszolgáltatások támadási felületét. Ez az egyetlen szűk keresztmetszet, ahol a biztonsági szabályzatokat következetesen érvényesítik.

A törött objektumszintű jogosultságkezelés (más felhasználó adatainak elérése az URL-ben lévő azonosító megváltoztatásával) következetesen a leggyakoribb API-sérülékenységként szerepel.

Hogyan hozzunk létre egy API-t?

1. Először a szerződést határozd meg

A kód megírása előtt határozd meg, mit fog az API csinálni. Az OpenAPI Specification (korábban Swagger) segítségével írd le minden végpontot, annak paramétereit, válaszformátumát és hibafeltételeit egy géppel olvasható YAML- vagy JSON-dokumentumban. Egy jól megírt OpenAPI-specifikáció a következőként szolgál:

• Tervezési eszközként, amely a megvalósítás előtt világosságra kényszerít
• Szerződésként, amelyen a frontend- és backendcsapatok párhuzamosan dolgozhatnak
• Automatikusan generált dokumentáció, kliensoldali SDK-k és mock szerverek forrásaként

2. Válassz architekturális stílust

A legtöbb új API esetében a JSON-t használó REST az alapértelmezett választás — széles körben ismert, gazdag eszköztámogatással rendelkezik, és a legtöbb felhasználási esethez elegendő. Válassz GraphQL-t, ha a klienseknek rugalmas, kliensvezérelt lekérdezésekre van szükségük, és az alullekérdezés ismert probléma. Válassz gRPC-t, ha nagy átviteli sebességű, alacsony késleltetésű, belső szolgáltatások közötti kommunikációra van szükséged.

3. Valósítsd meg a háttérrendszert

Építsd meg az API-szerződést teljesítő szerveroldali logikát. Ez magában foglalja:

• A definiált végpontoknak megfelelő HTTP-útvonalak beállítását
• Kezelők (handlerek) írását, amelyek érvényesítik a bemenetet, meghívják az üzleti logikát, és formázzák a válaszokat
• Kapcsolódást adatbázisokhoz, gyorsítótárakhoz és más háttérszolgáltatásokhoz
• Hitelesítési és jogosultságkezelési middleware megvalósítását

4. Dokumentáld az API-t

A dokumentáció nem utólagos gondolat. Ez az első dolog, amit az API-t integráló fejlesztő látni fog, és ez határozza meg, hogy sikerrel jár-e vagy feladja. A jó API-dokumentáció tartalmazza:

• A hitelesítés áttekintését (hogyan szerezz kulcsot, hogyan illeszd be a kérésekbe)
• Minden végpont referenciáját példakérésekkel és -válaszokkal
• A hibakódokat és jelentésüket
• A sebességkorlátokat és a lapozási konvenciókat
• Változásnaplót vagy verziótörténetet

Az olyan eszközök, mint a Swagger UI, a Redoc és a Postman, interaktív dokumentációt generálhatnak egy OpenAPI-specifikációból, így a fejlesztők közvetlenül a böngészőben tesztelhetik a végpontokat.

5. Teszteld az API-t

Az API-tesztelés ellenőrzi, hogy a megvalósítás megfelel-e a szerződésnek — és terhelés alatt is helytáll-e. A tesztelési kategóriák a következők:

• Funkcionális tesztelés: Minden végpont a helyes választ adja-e érvényes bemenetre, és a helyes hibát érvénytelen bemenetre?
• Integrációs tesztelés: Az API helyesen működik-e, ha valódi adatbázisokhoz, hitelesítési szolgáltatásokhoz és downstream rendszerekhez csatlakozik?
• Terheléses tesztelés: Hogyan teljesít az API egyidejű kérések esetén? Melyik ponton ugrik meg a késleltetés, vagy jelennek meg hibák?
• Biztonsági tesztelés: Egy nem hitelesített kérés hozzáférhet-e egy védett végponthoz? A bemenetellenőrzés blokkolja-e az SQL-injekciót és a cross-site scriptinget?

6. Helyezd üzembe API Gateway mögött

Irányítsd az éles forgalmat egy API Gateway-en keresztül, amely kezeli a TLS-megszüntetést, a hitelesítést, a sebességkorlátozást és a megfigyelést. Helyezd üzembe az API-t konténerizált vagy szerver nélküli környezetben, amely a forgalom növekedésével horizontálisan skálázható. Folyamatosan figyeld a késleltetést, a hibaarányokat és az átviteli sebességet — és állíts be riasztásokat az alapvonaltól való eltérésekre.

Mi az API-tesztelés?

Az API-tesztelés az a gyakorlat, amely ellenőrzi, hogy az API a specifikáció szerint viselkedik-e — a megfelelő adatokat adja-e vissza érvényes kérésekre, a megfelelő hibákat érvénytelenekre, és megtartja-e a teljesítményt a várható terhelés mellett. Eltér a felhasználói felület tesztelésétől: nincs böngésző, nincs oldalmegjelenítés, nincs vizuális elrendezés, amelyet ellenőrizni kellene. A teszt HTTP-kérést küld, és ellenőrzi a választ.

Az API-tesztelés a következőkre terjed ki:

• Szerződéses tesztelés: Az API-válasz megfelel-e az OpenAPI-specifikációban definiált sémának? Minden kötelező mező jelen van-e? Helyesek-e az adattípusok?
• Funkcionális tesztelés: A GET /commissions/123 a 123-as jutalék adatait adja-e vissza — és kizárólag a 123-as jutalék adatait? A POST /commissions érvényes bemenettel új rekordot hoz-e létre, és 201-es státuszt ad-e vissza?
• Hibakezelés: Hiányzó kötelező mező esetén a kérés 400 (Bad Request) választ ad-e? Lejárt token esetén 401 (Unauthorized) választ? Nem létező erőforrásra irányuló kérés esetén 404 (Not Found) választ?
• Teljesítménytesztelés: Hány egyidejű kérést bír az API, mielőtt a késleltetés meghaladná a szolgáltatásszint-célt (SLO)? Hol van a töréspont?
• Biztonsági tesztelés: Elutasítja-e az API a hitelesítés nélküli kéréseket? Megakadályozza-e a hozzáférést azokhoz az erőforrásokhoz, amelyek nem a kérő tulajdonában vannak?

Az automatizált API-tesztek — amelyek minden commitnál futnak a CI/CD-folyamatokban — még azelőtt elkapják a regressziókat, hogy azok éles környezetbe kerülnének. Az olyan eszközök, mint a Postman, a REST Assured és a Supertest, gyakorlativá teszik olyan tesztsorozatok felépítését és karbantartását, amelyek minden végpontot lefednek.