V ramci ITMS2014+ pripravuje pre verejnost API na vytvaranie vybranych objektov/formularov.
V ramci implementacie projektov podporenych z eurofondov najvacsiu reziu a administrativnu zataz prijimatelom robi:
evidovanie uctovnych dokladov,
dokladovanie podpornej dokumentacie/priloh k narokovanym vydavkom v ramci ziadosti o platbu,
Vyssie uvedene data subjekty uz maju u seba v digitalnej podobe (napr. uctovnictvo, scany a pod.).
Zaroven ziadost o platbu je najcastejsie predkladany formular v ramci celeho procesu implementacie eurofondov v SR.
Z tychto dovodov pripravujeme API pre umoznenie:
vytvarania uctovnych dokladov,
vytvarania ziadosti o platbu so zakladnymi atributmi ziadosti a jednotlivymi prilohami.
Existuju v ramci pripravanych dokumentov nejake standardy/odporucania/best practices pre tvorbu tzv. “OpenAPI” v SR e-Governmente?
Zaujima ma:
API pre verejnost musi byt REST alebo je akceptovatelny SOAP?
aky sposob autentifikacie sa odporuca, aby to bolo lahko implementovatelne pre verejnost, aby vlastnik nemal velku reziu a manazment s pristupnovanim API a aby to bolo bezpecne, futureproof technologie?
Štandardy pre OpenAPI žiadne špecifické zatiaľ nie sú (ešte sme ich nenapísali ). V dokumentoch PS Lepšie služby sa pokiaľ viem rieši akurát začlenenie OpenAPI do architektúry. Všetky detaily by mali byť uvedené pri popise príslušného centrálneho komponentu, cez ktoré majú byť všetky OpenAPI dostupné - ten však zatiaľ samozrejme neexistuje. @jsuchal je tak?
Z platných štandardov pre ISVS vyplýva, že OpenAPI musí byť SOAP, viď. §11.a,b,c. REST sme “vybavili” ako povolený doteraz iba pre OpenData.
Autentifikácia: za normálnych okolností by samozrejme mal byť použitý centrálne manažovaný mechanizmus -
autentifikačný certifikát podľa §22aa z.305/2013. Keďže zasa raz niečo čo už malo podľa zákona povinne fungovať nie je ani v dohľade (register AC), si odkázaný na vlastné riešenie. Najbližšie tomu imho bude vydávanie vlastných X.509 certifikátov.
Dnes najväčšie fungujúce OpenAPI sú služby ÚPVS. Pevne verím, že nebude použité ako štandard, ale dokážeme spraviť niečo jednoducho použiteľné.
podla mna, v podstate je jedno, ci to je REST alebo SOAP, ale aby API bolo dobre spravene, zdokumentovane a aby bolo pristupne v DEV prostredi, nech si ho vie clovek osahat
kedze si to clovek teraz moze spravit najlepsie ako uzna za vhodne :), tak co sa odporuca? Poziadavky su:
futureproof technologia,
lahko implementovatelne na strane poskytovatela aj konzumenta API,
Pruser SOAPu je, ze sa tam pouzivaju tie “sice-standardizovane-ale-dnes-zriedka-pouzivane” kosate nadstavby ako ws-security - signing atd. Kedze komercia dnes fici na oauth/openid connect alebo nejakom jednoduchom podpisovani requestov, tak hentie xml sialenosti stracaju podporu v knizniciach. A cim novsia technologia, tym mensia sanca, ze toto niekto podporuje alebo maintainuje. My sme len kvoli tomuto museli siahnut po jruby a javovskej kniznici co to dokazala ako-tak (ked prizmurim vsetky oci) bezbolestne vyskladat.
Len ked sa vola po interoperabilite, tak prosim nezabudajme aj na opacny smer… XML a SOAP sice maju nevyhody, ale netlacme REST API aj tam, kde to nie je vhodne.
). V dokumentoch PS Lepšie služby sa pokiaľ viem rieši akurát začlenenie OpenAPI do architektúry. Všetky detaily by mali byť uvedené pri popise príslušného centrálneho komponentu, cez ktoré majú byť všetky OpenAPI dostupné - ten však zatiaľ samozrejme neexistuje.