Webinář je k dispozici ke shlédnutí zde: https://www.youtube.com/watch?v=M4e34Zs6AKM
Jak by mělo vypadat ideální bankovní API? Zeptali jsme se vývojářů na základě zadání z bank a výsledky dotazníku pro vás zpracovali.
16. 0 5,5 11 16,5 22
2
4
5
5
6
10
14
21
21
Přístup k účtům a zůstatkům
Přístup k transakční historii
Možnost založit novou platbu
Přístup k nezabezpečeným informacím banky
Přístup k jiným funkcím produktů (inkasa, trv. platby, ...)
Skóring klienta
Akviziční proces a založení klienta
Přístup k ostatním bankovním produktům (karty, investice, úvěry, ...)
Přístup k informacích o produktech banky (poplatky, úroky, výhody, ...)
23. • Datum od - do. Zbytek si zvládnu profiltrovat na klientovi lokálně.
• Filtrovani podle data je dostatecne, zbytek jde resit lokalne.
• Používat obecný dotazovací jazyk.
• Obecny dotazovaci jazyk.
• Facebook relay.
• Jednoduché filtry by měly v 95% stacit.
• Obecný dotazovací jazyk. Něco, co je odvozeno třeba z SQL nebo něčeho jinéhom
standardního.
• Obecný dotazovaci jazyk.
• castka, mena, datum.
• Atributy: cas, castka, +/-, c.uctu odkud/kam, obsah zpravy, obecny dotazovaci jazyk,
pro snadne rozsireni, kombinace kriterii povazuji za nezbytnou.
• Account number, VS.
• Numericky od-do, textovy regexpovym hledanim.
• Základní parametry preddefinovany, pro ostatní a kombinace nějaka notace pro možnost
and/or složitějších kombinací které aplikace na základě své chytristiky může použít.
Zároveň možnost si transakce tagovat s hodnotou a filtrovat na základě těchto metadat
• Adresát/příjemce, typ platby, kategorie ... určitě by bylo vhodné mít možnost filtrovat dle
více kritérií (ale není to nutné do verze 0.x)
24. • Není potřeba řadit, typicky je chci zobrazovat od nejnovější po nejstarší.
• Opet razeni podle data staci.
• Částky, Typ transakce
• Seznam atributu vcetne asc,des
• Facebook relay
• Jeden atribut by měl v 95% stacit
• Obecné řazení může být přímo součástí dotazovacího jazyka (viz SQL).
• Jeden atribut staci
• id, datum "zapocteni"
• Castky, datumy
• Podle času
• podle vsech, to by nemel snad bejt problem
• Více např datum a hodnota, datum a schvalovatel apod.
• Datum, objem a typ transakce (přích, odch, karta, poplatek). Řazení dle adresáta a
dalších parametrů mi nedává smysl.
25. Služba, kterou
chci “obalit”
aplikací
Externí
databáze a zdroj
dat
Pohled na bankovní API
Stačí základní řazení a filtry,
protože to tak doménově
dává typicky smysl.
Potřebuji komplexní
dotazování, chci umět
hledat komplexní souvislosti.
27. • Setup pro data plaťáku, Validate pro ověření dat platby, Create pro zavedení platby do
systémů, Commit pro autorizaci platby (např. pomocí TAN).
• Jeden endpoint pro platbu, rozdeleni na urovni bankovniho API nedava smysl, protoze z
pohledu UX v aplikaci jsou oba pristupy zamenitelne.
• Najlépe mít kombinaci validačního resource
• Kombinace validace na klientovi i serveru. Na klientovi zakladni validace na cisla uctu
(modulo), zapornost cisel apod.
• Pokud by se jednalo o REST API, tak by melo zustat stateless
• Jeden endpoint je nebezpečný, ale těžko říct, jestli dva kroky něco reálně vylepší.
• Jeden endpoint pro zadání platby s možností "dry run". Doplňování je problémem
klientského UI, ne API.
• Po jednotlivých fázích
• Flow různých produktů může být různé. Některé ocení 1 krokové vyřízení, u jiných bych
ocenil provedení validací, na základě kterých dostanu "zamčený" review.
• Posledni varianta tzn kombinace
• Jeden formát s rozdělovacím atributem: Validace nebo Submit (validace plus potvrzení)
• jeden endpoint staci
• Kombinace validacni endpoint a odesilaci, s tim ze validacni udělat cachovatelny aby si
to mohla aplikace urychlit ale mit aktualizovatelne
• První varianta - vše na straně poskytovatele, aby vývoj aplikace nad API byl co
nejjednodušší.
34. 15 %
15 %
31 %
38 %
V rámci aplikace 3. strany (bez prostředku banky)
Kombinace, resp. dle účelu
V rámci aplikace banky (IB, MB)
V rámci aplikace 3. strany (prostředkem banky)
37. 0 4,5 9 13,5 18
0
3
9
10
13
18
18
Důkladnou a detailní dokumentaci
Možnost jednoduše testovat na sandboxu
Možnost jednoduše testovat na živých datech
Open-source kód
Klientská SDK
Diskuzní fórum
Účet na sociálních sítích