Billingo.hu A Billingo online számlázó blogja. Gyors és élvezetes elektronikus számlázás.
Blog / Velünk történt / Billingo API 2.0…
Velünk történt - 2016.03.10. - 3 p. olvasás

Billingo API 2.0

A Billingo készítésénél külön prioritással kezeltük, hogy legyen külön API - azaz alkalmazás fejlesztési interfész ami a lehetőleg könnyen kezelhető. A Billingo 4.0 fejlesztéssel pedig az API is megújult. Összeszedtük a legfontosabb tudnivalókat a Billingo API 2.0-ról.

Billingo API

REST

Leegyszerűsítve, a Representational State Transfer a világháló szoftverarchitektúra stílusa. Azokat a szolgáltatásokat amik eleget tesznek a REST megkötéseinek, RESTful -nak hívják. A megkötésekről és a REST-ről részletesebben többek között itt is olvashatsz.

Annyi fontos, hogy a Billingo API által elérhető szolgáltatásait a GET, POST, PUT és DELETE HTTP metódusokkal érjük el. A GET a lekérdezésért, a POST a mentésért, a PUT a módosításért a DELETE pedig a törlésért felel.

A különböző szolgáltatásokat, mint például a számlák letöltése vagy partnerek feltöltése különböző URL-eken keresztül érhetjük el, ezek az ún. end-point-ok.

A másik elterjedt stílus a SOAP.

A Billingo már az első verzió óta, az egyszerűség, az elterjedt könyvtárak, könnyebb tesztelhetőség és egyéb okok miatt is RESTful API-t használ.

Új megnyitott szolgáltatások

Az eddigiek mellett szerettünk volna még több a Billingóban is használható szolgáltatást megnyitni az API felé. Ezek közül a fontosabbak:

  • Kiadások kezelése
  • Számlák kifizetésének a beállítása
  • Számlák emailben küldése
  • Számlák stornózása
  • Számlák letöltése

A régen visszaadott letöltési link pedig egy új endpointon lett elérhető. Ennek a használatával nyomon következő, hogy egy számlát megnyitottak-e vagy sem.

JSON

A JavaScript Object Notation egy kis méretű, ember által olvasható, nyílt adatstruktúra, amely ugyan a JavaScript nyelvből gyökerezett. Mára már teljesen nyelvfüggetlen.

Előnye az XML-el szemben, hogy sokkal kevesebb leíró adatot tartalmaz. Egyszerűbben szerkeszthető és gyorsabban feldolgozható.

A másik hasonló adatstruktúra formátum a YAML amit gyakran rendszer konfigurációhoz használnak.

Azt, hogy JSON-t fogunk használni az nem is volt kérdéses.

JSON séma

A JSON fájl séma mentes, ha nincs szintaxis hiba, akkor bármilyen mezőket tartalmazhat. Ez ugyan megkönnyíti a fejlesztést, de nehezíti a standardizálást egy API esetében.

Emiatt az egyik fő váltás az új API rendszerben a JSON-Schema használata lett. Amit a jelenlegi verzióban csak a fogadott adatokra terjesztettünk ki, azonban hamarosan már a visszaküldött adatokhoz is elérhetőek lesznek a JSON sémák.

További olvasni való a JSON sémáról: http://json-schema.org/

Hitelesítés

A REST állapotmentes, ez egyszerűbben mondva azt jelenti, hogy az egyik szolgáltatás elérése után nincs állapot információnk (pl. bejelentkezés, stb.) a soron következő szolgáltatás meghívása esetén. Emiatt minden szolgáltatás meghívásnál hitelesíteni kell, hogy melyik felhasználó hívta meg az API-t, volt-e joga hozzá. Lehetőleg biztonságosan. Tehát ha valaki "lehallgatja" a két rendszer közötti kommunikációt, akkor ne tudjon a bejelentkezési adatokkal más információt küldeni vagy letölteni.

Talán ez volt az egyik pont, ahol bakit követtünk el az első rendszernél. Viszonylag egyedi digitális aláírásos rendszert használtunk a hitelesítéshez, viszont főleg azért, mert nem volt szabad formátum. Nehézkesen volt használható, és nem volt mindig egyértelmű, hogy miért nem működik valakinél.

Emiatt a 2.0 -ás rendszerben már az ún. JSON Web Token azaz JWT-t használjuk a hitelesítéshez és minden esetben HTTP fejlécként adjuk át a hitelesítő kódot.

Ezzel talán sikerült tovább folytatnunk az ádáz küzdelmünket a szabványosításért. :)

Könyvtárak

Annak érdekében, hogy minél egyszerűbben használható legyen az új API, a jobb dokumentáció mellett (ami innen elérhető) új PHP könyvtárakat is írtunk. Mindegyik szabadon felhasználható, MIT licenszű.

Az első elkészült könyvtárak a Connector könyvtár, ami a HTTP hívásokat és az authentikálást segíti és ugyanez a könyvtár a Laravel keretrendszerhez.

Ezen kívül készülünk még egy DataMapper könyvtárral. Ez az összes szolgáltatást egyszerűen kezelhető osztályokká alakítja, és természetesen szeretnénk a későbbiekben további nyelvekre is lefordítani őket.

A könyvtárak elérhetőek Packagist -en is, és Composerrel telepíthetőek. Így folyamatosan és automatikusan frissen tarthatóak.

Címkék

Blog cikk értesítő

Blog cikk értesítő

Iratkozz fel, ha szeretnél tudni a számlázással kapcsolatos legfrissebb hírekről és érdekelnek az akciók.

Back to Top
Tudástár fejlesztés vállalkozás online számlázás Törvény NAV hasznos tippek új funkció e-számla online számlaadat szolgáltatás webáruház nav-bekötés könyvelés adózás KATA adatszolgáltatás kéziszámla marketing bejelentési kötelezettség számlasablon biztonság felhő digitális archiválás kata 2020 e-kereskedelem számlatömb katás vállalkozás adatszolgáltatási kötelezettség tévhitek kata adózás ügyfélszolgálat kata adatszolgáltatás pénztárgép startup billingo áfa számlázó program váltás online számlázó nav online számla regisztráció fenntarthatóság e-számlázás támogatás Bonácz Zsolt katás vállalkozás adatszolgáltatása kata bejelentés online számla regisztráció online számla és billingo összekötés nav online számla fintech számla felelősségvállalás Webshippy webáruház logisztika díjak elismerés GDPR katás számlázás egyéni vállalkozás PSD2 nyílt bankolás számlainformációs szolgáltatás kata megszűnése kata megszüntetése kata vállalkozás megszűnése banki összekötés összekötés Díjbekérő Proforma Számla kiállítása külföldre Külföldi számla kötelező tartalmi elemei Billingo előfizetés Ingyenes Billingo Online pénztárgép interjú e-számlák NAV bekötés ingyen hónapok Billingo ajánlói rendszer Billingo kupon Kedvezmény a számlán bevételi bizonylat online fizetés forbes flow opten minősítés szakértő fullfillment integráció erste PowerBill by Billingo cégjog Farkas Dezső Marketing Gyémánt Díj marketing diamond awards Az Év Honlapja előlegszámla előlegszámla készítése blog adó Instagram