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.

1. Bankovní
API - Jaký je
ideál?
#8

2. Petr Dvořák
CEO at Lime
E-mail: petr@lime-company.eu
Twitter: @joshis_tweets

3. Sdílejte přátelům a známým
Otázky lze klást v Q&A boxu
Odkaz na Slideshare v popisu videa
Záznam bude dostupný on-line

4. Výsledky dotazníku ve formátu CSV
https://dl.dropboxusercontent.com/u/6405782/Bankovn
%C3%AD%20API%20-%20vysledky%20dotazniku.csv

5. Demografické údaje

6. 23

7. 100 %
Muži Ženy

8. 4 %
9 %
83 %
4 %
19-26 let 27-35 let 36-45 let 45-55 let

9. Technologie

10. Jaké aplikace vyvíjíte?

11. 0 4 8 12 16
2
10
14
15
Webové aplikace Mobilní aplikace Interní systémy a API
Desktopové aplikace Jiné

12. V jakých programovacích
jazycích pracujete?

13. 0 2,5 5 7,5 10
1
3
4
4
6
6
9
9
9
10
Java Objective-C PHP JavaScript Swift C# Ruby
C++ Python Kotlin

14. Funkčnosti API

15. Jaké funkčnosti byste
nejvíce ocenili?

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, ...)

17. Technikálie API

18. Jaký přenosový formát by
mělo API podporovat?

19. 4 %
9 %
87 %
JSON Jiné - Protocol Buffers XML i JSON XML

20. Jak by mělo být řešené
stránkování seznamů?

21. 18 %
41 %
41 %
since, itemCount itemOffset, itemCount
pageIndex, pageItemCount

22. Jak byste řešili řazení
a filtrování dat

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.

26. Jak by měl být realizován
proces placení?

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šší.

28. Podepsání Zadání
Setup Validace
Proces platby?

29. Validace Zadání

30. Bezpečnosti API

31. Jaký protokol by měl být
použit k zabezpečení API?

32. 5 %
5 %
89 %
OAuth 2.0 Form-based TAuth

33. Jak by měly být
autorizovány platby?

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)

35. Nefunkční požadavky

36. Které nefunkční požadavky
byste nejvíce ocenili?

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

38. V jakém jazyce by měly být
tvořeny příklady?

39. 19 %
24 %
57 %
Nějaký jazyk, který znám Můj programovací jazyk
Nepotřebuji příklady, stačí dokumentace

40. Děkuji
Petr Dvořák
e-mail: petr@lime-company.eu
twitter: @zinglyapp
http://zingly.cz/

41. Otázky? :-)
Petr Dvořák
e-mail: petr@lime-company.eu
twitter: @zinglyapp
http://zingly.cz/