Taky sharepoint to ma v zaklade a ten je celkom rozlezeny po svete a najma nasich statnych is. v tom dokumente som to pisal, tu je zoznam: http://www.odata.org/ecosystem/
Je to taky trocha viac standardizovany REST, - co nemam rad na cistom reste je to podstatne jednoduchsie na implementaciu ako robit odzakladu rdf + sparql, ten da sa da aj na odata vybudovat.
Momentalne sa da vo vnutri orgarnizacii pouzivat iba SOAP 1.2 co je obmedzujuce. Neviem aky bol dovod obmedzit REST iba na opendata
K veci. Ten protokol je dost kanon na vrabce, kedze vyzaduje take osekane SQL pre pristup k datam. SOAP toto neriesi, riesi len sposob komunikacie a ake sluzby sa maju poskytovat nechava tak (co je imho spravne).
Na jednej strane by bolo fajn mat take api na vsetky data, na druhej strane by som to nechcel robit kedze vacsinu toho protokolu nikto nikdy potrebovat nebude. Ak ide o vymenu dat, staci synchronizacne api, SQL endpoint, etc. Jednoduchsich moznosti je dost.
Som urcite za standardizaciu, ale nie som si isty ci tu zbytocne pridavame robotu navyse. SOAP a OData podla mna riesia dost rozlisne veci.
Btw. pokial viem toto je open “data protocol” nie “open data” protocol. Na open data sa to vyuzit da, ale nie je to primarne ono a tej funkcionality je tam zbytocne viac, vyrabaju novy dopytovaci jazyk. Paci sa mi ako toto vyriesil novy data.gov.sk, ktory proste vystavil SQL endpoint kde viem poslat dopyt. SQL je linqua franca snad kazdeho vyvojara IS.
Ja to nemam v plane iba na open data. Problem je, ze dovnutra statnej orgranizacie je mozne vyuzit iba SOAP a nic ine (55/2011 §11), ziadny SQL endpoint, ziadny REST, proste nic jedine SOAP, a tu sa ludia pretekaju vo vymyslani novych sposobov pre dopytovanie dat. Usetrilo by to kopec casu a penazi keby bola moznost pouzit ine moznosti ako dokola vytvarat nove metody cez soap. Idealne by bolo asi povolit REST a potom sa da aj toto pouzit.
ja sa osobne priklanam rozsirit moznost vyuzivania RESTu a OData v4 vobec do vynosu nepliest. je to zbytocna komplikacia.
Je to tak ako @jsuchal pisal. REST sme tam tlacili koli opendata a kedze nik neriesil tento kontext ohladom integracie tak bol vynos upraveny tak aby opendata mohli zit svojim zivotom. Myslim, ze nik nemaml zaujem nejak pretlacat SOAP a potlacat REST. standardizacia funguje dost na zaklade iniciativy clenov komisie. My za soit.sk a Opendata.sk sme mali jasny ciel umoznit opendata api. Cize moj navrh je upravit len to obmedzenie rest na opendata a umoznit jeho plosne pouzitie.
Vo velkej miere suhlasim s poslednym prispevkom @jsuchal na tuto temu. Taktiez mi pride ze ci si zbytocne vec nekomplikujeme novym dopytovacim jazykom. Nakolko je to medzinarodny standard, tak by to nemusel byt az taky problem to mat povolene. Len aby to nebolo viac kontraproduktivne ako prinosne. Priklanam sa k navrhu @gla ako takemu rozumnemu kompromisu.
Myslim si ze zdielanie dat medzi systemami je vacsinou medzi strukturovanymi databazami (v drvivej vacsine relacnymi) a nie medzi nestrukturovanymi databazami(CMS), ktorych predstavitelom je prave spominany sharepoint. Podpora by preto musela byt priamo nad databazami na ktorych to bezi a tu sa uz dostavame k spominanemu SQL endpointu, kde aby nemali vsetky systemy pristup ku vsetkym datam, tak by sa robili specificke VIEWs kde by si nad nimi robili dopyty ake potrebuju. Stale mam taky pocit ze toto sa snazi SQL endpoint v okliesnej podobe emulovat + ma novy dopytovaci jazyk, je to v principe tak? Co by to prinieslo navyse?
SPARQL resp. RDF data - ano, je pravda ze na takyto endpoint je nutne mat data v tejto podobe a v sucasnosti je drviva vacsina dat v SQL databazach, kde takato podoba nie je, ale… Europska unia ako aj samotny plan rozvoja presadzuje vytvaranie referencnych identifikatorov ako aj vyuzivanie standardizovanych datovych schem(ontologii) vramci EU ale aj vnutrostatnych systemov, aby sa dali lahko zdielat udaje napriec systemami cim sa defakto dostavame k RDF datam. Preto by sa situacia tymto smerom mala zlepsovat. Takisto si uplne nemyslim ze SPARQL Endpoint a OData dokazu poskytnut take iste data nakolko je to databazovy jazyk a znova by to bolo len okliestene. Kazdopadne samotny priestor pre SPARQL endpoint vidim v tejto faze hlavne v oblasti otvorenych dat.
tl;dr: idealne by bolo ak sa schvali REST na pouzitie, potom by bol tento navrh je bezpredmetny.
Keby bol povoleny REST tak by to uplne stacilo kedze OData je len daka forma standardizacie REST ked to tak za vlasy pritiahnem.
Mozem zrusit tuto moju iniciativu ked uvidim ze REST bude mat sancu, lebo v tom dokumente na pripomienkovanie vznikol nasledovny komentar
neviem v akom je to teraz stave ale ucinost 55/2014 konci za 3 mesiace a netusim co bude v novej/novelizovanej.
Ja v tom vidim vyhodu ze to spaja prave rozne typy technologii pod jednu strechu a jeden standardny typ volania. Navyse oproti SQL endpointu je vyhoda v tom, ze je zalozeny na http protokole a teda je to pouzitelne v modernych aplikaciach (web, mobil). Poskytuje urcitu formu kontroly and priamym pristupom do db alebo k inemu zdroju dat.
Pre mna nevyhoda cisteho REST je, ze nema sam v sebe definovany kontrakt a ani model a je nutna dokumentacia navyse, navyse kazdy implementator si moze vybrat inu cestu a vznikne v tom gulas, kde velmi podobne problemy maju uplne ine riesenie (hrube programatorske prirovnanie je porovnanie jazykov javascript a java).
tak sparql je idealny, ale je k nemu vedie velmi dlha a namahava cesta, ale aby sme nemuseli cakat az na ciel tak sa da jednoducho pouzit odata.
Skusme sa trochu vratit o krok spat. Aky problem sa snazis vyriesit? Ja som to pochopil tak, ze API na zdielanie dat si kazdy robi po svojom. Jeden vrati XML synchronne, dalsi asynchronne, dalsi zozipovane zavesi na FTP atd atd. Toto REST nijako neriesi a ostaneme tam kde sme boli. Ak sa pozriem do komercie (do mojej oblasti), tak ani tam ziadna velka standardizacia API co sa tyka zdielania dat zatial neexistuje.
Kam mierim, ak je problemom to, ze chceme standardizovat sposob akym sa bude pristupovat k datam, tak to je legitimny ciel, ale REST ako taky ho neriesi. Otazka, ze ako REST/OData a existujuce SOAP sluzby budu koexistovat je na mieste. Neexistuje ekvivalent OData pre SOAP?
Vadi mi, ze kazdy system pouziva ine zvyklosti na zdielanie dat ci uz cez SOAP alebo REST (kde bohuziual neexistuje standard ale iba iba konvencie), OData je standard a definuje “konvencie” na pracu s datami a ciastocne riesi problemy s nestandardizaciou REST-u. Vacsina REST sluzieb s ktorymi som pracoval prave riesi taketo operacie ake poskytuje OData.
Bohuzial k SOAP nic take neexistuje, trochu sa SOAP a OData prekryvaju ale odata je na zdielanie dat a soap na vymenu sprav.
Dovod preco by mi ciastocne stacil REST je, ze rad by som OData pouzil v projektoch pre stat ale preco musim nutit stat platit za dlhe analyzy a/alebo implementacie niecoho co uz existuje a 55/2014 to nedovoli pouzit?
Existuju implementacie serverovske OData pre .NET, Javu, Python, Javascript a nasobne viac klientskych implementacii, vsetko s idealnymi licenciami. Existuju aj platene podpory a produty.
Čo bude v štandardoch od 1.7.2016 vieš zistiť veľmi ľahko:
Stručne povedané, vo veciach o ktorých sa tu bavíme sa nezmení nič.
Ku histórii - povedzme si otvorene, REST sme navrhli na použitie všade, ale (vtedy) nebol záujem, ani od realizátorov projektov. Otázne je, čo budú chcieť teraz.
Úplne súhlasím s tým, že v API na zdieľanie dát je guláš. A imho je treba spraviť tu novú štandardizáciu. Mať povolené použitie SOAP aj REST všade je iste základ. V tomto sa zatiaľ všetci zhodujeme.
Tým sa síce umožní jednoduchšia implementácia synchrónnych bezstavových API, avšak guláš to nezmenší. Rovnako ako @peterk som presvedčený že je čas mať jednotné API na výmenu údajov. Ja hovorím o komunikácii na úrovni registrov. Tu treba vyriešiť nasledovné veci:
identifikátory objektov - použime URI podľa už platného štandardu
štruktúra dát - máme dátové prvky
verzia údajov - aktuálny stav vs. verzia platná v určitom čase
autorizácia údajov (aby boli použiteľné na právne účely) - autorizácia transportného kanála? ZEP? voliteľne?
identifikácia žiadateľa (a overenie že má prístup k údajom) - autentifikácia? SSL cert? SAML token?
query - aké funkcie sú skutočne potrebné
aktualizácia údajov - inicializácia/zmeny, push? neriešiť?
Spravme si predstavu čo treba s týmito ^ vecami, následne sa zvolí protokol/API.
Možno z toho aj výjde že OData s ďalšími upresneniami je vhodné.