Doplnim tam teda, ze zapis je vykonavany prostrednictvom podania?
Prosim nie. Toto je standard, ktory hovori ako sa maju zapisy robit, nie co sa ma otvarat alebo zatvarat. Ked sa zajtra zmeni legislativa, tak budem kvoli tomu prepisovat standard? Podla mna to su len okrajovo suvisiace veci. Ak sa ma otvorit api na podania, tak nech a trebars podla tohto standardu, ale nefixujme to len na podania.
1 Like
súhlasim s @jsuchal , som to tu dal len ako príspevok do diskusie, mne sa tento záver vôbec nepáči a snažím nájsť nejaké riešenie/návod ako ktomu zápisu pristupovať. totiž API ala elektronické podanie má dve základné nevýhody:
- neviem dostať okamžitú (online) odpoveď ak je možná, ba ani priamu, odpovede idú cez cez schránky
- generické rozhranie, ktorým môžem síce všetko, ale odladiť cez to konkrétny prípad je veľký problém
Ono totiž pohľad read/write sa možno dá použiť na údaje, ale nie na služby. Je množstvo služieb, ktoré nie sú “read only” a nie sú to ani podania. Napr. v posledných týždňoch hojne diskutované revokovanie certifikátu v eID.
Btw. samotné API na podanie samozrejme má existovať, je to dôležitá služba. A malo by byť verejne dostupné aj bez integrácie a autentifikácie - predsa niektoré podania môžu byť aj anonymné, a iné sú zasa autorizované ZEPom (takže netreba autentifikáciu).
Ináč teraz od 1.11. nová autorizácia použitím služby IS (aka autorizácia kliknutím) je vlastne preklenutím historického nezmyslu, že všetky podania musí ísť formulár->schránka->ZEP->odoslanie.
Ani nie, ja to nateraz chápem, že formulár->schránka->niečo iné ako ZEP (klik) ->odoslanie, pretože v zákone:
ak sa zabezpečí uvedenie tejto osoby ako odosielateľa elektronickej správy, nemennosť obsahu autorizovaného dokumentu do momentu uloženia v elektronickej schránke adresáta, spojenie autorizovaného dokumentu s identifikátorom osoby odosielateľa a zachovanie väzby medzi nimi, ak to osobitný predpis nezakazuje alebo
to naozaj ideme toto zivit. Ved sa iba pozrite spatne na hicktore udalosti, ktore organizujete, vzdy nas tam chcete signutych cez nejaku thirdparty alebo priamo, preco by to malo byt inak v eGove?
No lebo podanie naozaj moze doniest na podatelnu hocikto? Lebo je to tak v zakone napisane? (@lubor isto rad vytiahne paragraf.)
1 Like
OpenDataAPI službe nevyžaduje prihlasovanie, špecifické povolenia ani prístup cez API Gateway
K tomuto mam jednu poznamku: Podla mna by bolo dobre zadefinovat co ma API Gateway robit. Lebo pre mna je to cisto technicky “layer” tak ako to ma amazon/getkong.
Za mna:
- vie to robit rate limiting, overovanie tokenov (nie biznis logika, len podpisy) a nie nutne ich vydavanie, to robi centralny modul, vie to mozno nejake analytiky niekam reportovat.
Z tohto pohladu ak toto bude postavene ako SaaS trebars aj vo vladnom cloude, tak nie je dovod aby to nepouzivali aj opendataapis. Rate Limiter sa vzdy hodi, monitoring/reporting tiez.
Za nutnost to pouzit napiec vsetkymi APIs to uplne nepovazujem - za predpokladu, ze to vie niekto vo vlastnej rezii lacnejsie v rovnakej kvalite a standardoch.
1 Like
API Gateway by mozno bolo fajn dopisat, aby bolo jasne co to predstavuje. Za mna by som tam dopisal toto :
API Gateway je technicky komponent, ktory zabezpecuje:
- verejne prístupné proxy, prostredníctvom ktorého je riadený prístup pre registrované OpenAPI služby
- počítanie prístupov k elektronickým službám za účelom spoplatnenia alebo obmedzenia prístupu po prekročení limitu definovaného poskytovateľom elektronickej služby
- overovanie prístupových tokenov
- zverejňovanie štatistík prístupu v štruktúrovanej podobe k jednotlivým službám
- monitoring elektronických služieb a zverejňovanie v Centrálnom metainformačnom systéme
Kazdopadne co sa tyka toho ze ci a kde prihlasovanie/gateway ano tak preto je tam ze sa to “nevyzaduje” ale to neznamena ze “nesmie”. Proste kto bude chciet tak si to tak spravi, ale aj ITMS vie zit bez toho. Ciel bol minimalizovat naroky na publikaciu otvorenych udajov cez API a preto som to napisal tak aby boli tie komponenty pre OpenDataAPI OPTIONAL.
3 Likes
Na druhej strane asi chceme vediet ako hojne su dane udaje vyuzivane. Co by sme mohli ziskavat prave z APIGW (kde to uz tak ci tak bude) a neimplementovat pre OpenDataAPI tento zber o vrstvu nizsie…
API Gateway je koncept, ktorý plní určité funckie. Kto chce si ho môže vytvoriť svoj, ale bolo by dobré mať aj jeden centrálne prevádzkovaný, pre tých ktorí to nechcú/ nie je to ekonomické.
Jeho hlavná úloha je oddelenie backendu ISVS od “sveta vonku”. Čiže bezpečnosť, riešenie kapacít (v podstate je jedno akým spôsobom, môže to byť best-effort, alebo nejaké SLA, rate limiting atď.).
Mne skôr nie poriadne domyslený pripadá ten “scope”. Čo presne to je? Kto ho definuje?
Na margo APIGW a jej funkcii… to naozaj nikto nepozerate tie bledomodre obrazky v tych strategickych prioritach :)? A to je tu tolko uber-architektov…
No a nie je lepsie odburat bariery pri autentifikacii v digitalnych kanaloch a radsej to vzdy vyzadovat ked prihlasenie bude easy?
A co ked to je v zakone, nechceme to zmenit?
Integracne middlewares ako apigw alebo esb nemozu byt zo svojej povahy postavene ako SaaS. Nemozu disponovat ziadnou biznis logikou (odhliadnuc od “docasnych” workarounds). V
Takze opat kuk Integracia a Orchestracia 
Mas pravdu je to tam. (SP Integracia orchestracia, keby niekto hladal).
Ale toto si tu takto odlozim, aby sme sa potom zasmiali ked sa bude robit obstaravanie na API-GW a nebodaj uvidime vysledok.
Potom asi nerozumiem co myslis pod SaaS alebo API GW. Lebo toto je naopak uplne bezne. Vid https://www.quora.com/Is-there-a-SaaS-for-API-management
No to iba preto ze zase uraduju salesaci. Ma to byt PaaS, nakolko je to technicky layer / medzivrstva. Gro je aj tak na a za APIs.
Okrem toho by si sa cudoval co to stoji postavit v komercnej firme cross cely omnichannel a 24/7 support s rozumnou dostupnostou :). Uz iba tie sprchy nieco stoja.
2 Likes
Prečo človek, čo sa nevie prihlásiť, nemá možnosť spraviť elektronické podanie?
Prečo softvér, ktorý vie zložiť elektronické podanie, má riešiť nejaké prihlasovanie niekoho niekam?
Ad API gateway: v oboch dokumentoch SP sa vhodne píše o “platforme”. Škoda by bola aby (opäť) všetci museli čakať na vybudovanie centrálnych komponentov (najmä ak niektoré z nich majú zatiaľ dosť abstraktné zadanie). Povedzme teda, čo má API gateway spĺňať a minimálne v prechodnom čase dajme každému možnosť vystaviť API priamo (t.j. cez lokálnu inštanciu API GW).
Ináč keď sme pri modrých obrázkoch, prečo Spoločné moduly FE nepoužívajú tiež API GW, ale majú byť pripojené priamo na zbernicu?
Tak sa mi zdá, že niekto čítal kapitolu 7 dokumentu Detailný akčný plán.:
Služby tak budú vytvárané (alebo prepracované) do rozhraní definovaných metodikou a ich samotnú publikáciu následne zabezpečí centrálny projekt WebAPI GW.
Nie je nutné čakať až do vytvorenia centrálneho komponentu, ale je možné postupovať podľa pripravovanej metodiky (ÚPPVII), ktorá bude záväzná jednak pre publikujúcu stranu (vlastník služby) a aj budúceho gestora komponentu WebAPI GW.
1 Like