Uplne na zaciatok jedno zakladne voditko: Nesnazit sa robit veci na dva krat: raz “normalne” (na internu potrebu) a raz “Open Data”.
Stava sa, ze niektore interne tabulky mozu obsahovat nieco “citlive” (a teda SELECT * ... by pre Open Data nebol dobry), ale zvycajne sa nad tou internou tabulkou da spravit aj iny - verejny - pohlad (SELECT verejna_vec_1, ...).
Tiez je mozne, ze Open Data budu robit na system vacsi load. Vtedy sa da spravit druha read-only replika (pripadne s mensim objemom dat - vid vyssie).
Dalej, par konkretnosti (o.i. doplnim, co nacal @jsuchal).
Ako naznacil Jano, prioritou maju byt “raw data”. Dovody:
-
Ak to v nejakej strukture potrebuje (resp. mu staci) niekto na urade, malo by to stacit aj 3rd party developerom. (ak by ta struktura nevyhovovala ani samotnemu uradnikovy, nuz to by bol dovod na prerobenie IS
) A teda aby sa veci nerobili dvojmo, zvrejni sa to co je tak ako je. -
Sumare a priemery limituju re-use, lebo sa napr. na agregatoch uz nedaju urobit niektore druhy analayz a pod.
Zverejnenie “raw dat” sa zvycajne robi najlahsie zverejnenim dumpov. Najma ak na zaciatok nie je jasne, komu by to na co bolo.
Potom, ked sa na tie dumpy uz niekto pozrie a bude mat otazky, da sa s nim viest zmysluplny dialog na temu ci aj API a ak ano, ake.
Ak je aj tak chcene robit API hned na zaciatku, tak dobry pristup je “API first”, t.j. vyuzit to, ze sa robi uceleny IS ktory bude poskytovat niekomu nejake (zmysluplne) funkcie. Zjednodusene: IS ma zvycajne back-end a front-end. Nuz a “API first” znamena, ze sa spravi back-end, nad nim sa spravi API a front-end vyuziva (len) toto API. A to API sa potom (mozno po drobnych upravach) reusne aj pre Open Data (idealne pamatat na to uz pri designovani API).
Ako uz tiez pisal @jsuchal a ini, netreba sa snazit mat to “100% super” hned na prvy krat. Treba spravit beta verzie, treba to nechat ludom pripomienkovat, netreba sa bat veci redesignovat ak testy ukazu ze nieco nie je uplne OK.
- subory (a.k.a. dumpy): CSV alebo XML (idealne taky, co sa da otvorit v tabulkovych procesoroch)
- API: RESTfull, JSON alebo XML
Vid Vynos 55/2014: http://www.informatizacia.sk/standardy-is-vs/596s
https://developer.github.com/v3/ ma +1 aj za mna, o.i. kvoli prikladom s vyuzitim curl.
Co najviac veci ma byt jasnych uz z pozretia sa na URL a z obsahu toho, co z daneho URL dostanem. Dokumentacia ma byt co najstrucnejsia (ak strucna dokumentacia nestaci, zrejme je nieco zle v API alebo je nejako “vadny” uz cely IS ).
A ako spomenul @Neco, je dolezite nejako “linkovat” jednotlive datove zaznamy na dalsie “dokumenty”. K tomu doplnim, ze ak referencujeme “mimo vlastny dataset” (t.j. na data niekoho dalsieho), je idealne pouzit URL (referencovatelny identifikator, ktory ked zadam do browsera, ziskam informacie tykajuce sa daneho “ID”). Ak sa neda, tak ine jednoznacne ID (a v dokumentacii napisat, ze kde a ako si info k danemu ID potom inde viem dohladat). Priklad: Zaznam o prideleni penazi by mal obsahovat zrejme ICO (toho, kto nieco z fondov dostal a … uz kvazi vsetci vedia, kde si maju ist hladat podrobnosti o organizacii na zaklade ICO), mala by tam byt linka na suvisiace dokumenty (ziadost, jej prilohy, dekret o schvaleni, …), atd.