Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Zabanovaný Anonymní Troll 03. 04. 2019, 16:37:42
-
Jsem jediny komu prijde absurdni, ze se i v enterprise informacnich systemech zacina rozmahat pouzivani Swaggeru na modelovani API pro komponenty, ktere potrebuji mit API jako RPC a ne jako Resource?
Tahle technologie, u ktere spolecnost co za ni stoji mela tu drzost ji pojmenovat jako OpenAPI, je utter crap.
Maly skok do historie. REST byl vyvinuty jako soucast HTTP v roce 1990 a je urcen pro modelovani webovych api typu Resource, tzn. webovka ma nejaky svuj backend, ze ktereho si potrebuje tahat data, zapisovat, updatovat atd. Je to neco designem dost spjateho s HTML, ktere se prenasi pres HTTP v RequestBody at uz pri GET, nebo kdyz se odesila nejaky formular, nebo co ja vim.
Dneska se za valecneho pokriku prumernych opic vyvojaru vytlacuje z backendu SOAP, nadavajic na to, jak je neflexibilni, pricemz se to nahrazuje necim tak naprosto nevhodnym, jako je Swagger api a rest. Samotny REST neni az zase tak problem, i SOAP se prenasi pres HTTP kde metoda je vzdy POST, problem je az teprve Swagger.
Backendove komponenty mezi sebou potrebuji delat RPC volani a ne si vzajemne sahat do Resource. Pouzitim Swaggeru, ktery je RPC dost unfriendly a nuti do Resource, vznikaji totoalni narovnavaky na ohybaky, protoze korporatni vyvojari jsou zmateni, nevi co to RPC vlastne vubec znamena a vo co go, a implementace Swaggeru je mystifikuje do tvorby kockopsa mezi RPC a Resource API. Swagger je navede na to, aby delali Resource API (vetsina ani nevi, co to je), jenze to jim v drtive vetsine pripadu nepasuje na to, co potrebuji delat, coz vsak vedome nevi, takze do toho michaji RPC az nakonec vznkne naprostgo zpackane gulas API.
Kdyz se k tomu prida zaklinadlo OpenAPI a prihodi se rvouci opico-ovce, tak z toho je dalsi jedna velka vyvojarska tragedie, ktera zase pro jednou vede k horsimu a zpackanejsimu backendu.
Clovek by rekl, ze by se mela metodologie vyvoje hybat dopredu, a ne dozadu a jeste dal.
Prohlasuju, ze kvuli Swaggeru se enteprise dostal z roku 2019 nekde do stavu vyvoje API pred rokem 2000, nez byl vymyslen SOAP. A to jsem jeste nemluvil o nahrazovani XMLek jinymi, "lepsimi" formaty.
Docela by me zajimal nazor mistnich.
-
Ak som to pochopil správne tak jediný problém je, že tam kde ste mali použiť RPC máte REST. Použili ste dobrú technológiu na nesprávnom mieste a teba to serie. Vaša chyba.
PS: Prečo tam nedáte GraphQL?! :D
-
Nejhorsi neni ani tak pouziti lehce nevhodne technologie, ale neustale zmenyv technologii. Jeden tyden rest, pak grpc, pak zas neco jineho.
-
A v čem to tedy přesně vadí? Vadí Vám bezstavovost - nebo?
-
Vlastne souhlasim s tim postem. Dnes kazdy proklamuje ze zna REST a pritom netusi co je to SOAP. Stejne tak, jako pro IPC komunikaci pouzije zcela nevhodne napr. nanomsg, namisto toho, aby se protokol udelal nad UDP, nebo TCP. Myslim ze je to dusledek toho, ze dnesni mladi lidi neznaji historii a nedokazou se z ni poucit nebo ji aplikovat.. a sahaj po trendy resenich, ktere jsou mozna v jedne veci lepsi, ale ve vsech ostatnich horsi. Z programatoru se stavaji lepici kodu, co se bez trendy knihoven a stackoverflow nezmuzou vubec na nic. Ale neplati to jen u programovani.. typicka rodinna situace - dnes varis ty - ... a uz leze na damejidlo.cz a pod :))
-
Vlastne souhlasim s tim postem. Dnes kazdy proklamuje ze zna REST a pritom netusi co je to SOAP. Stejne tak, jako pro IPC komunikaci pouzije zcela nevhodne napr. nanomsg, namisto toho, aby se protokol udelal nad UDP, nebo TCP. Myslim ze je to dusledek toho, ze dnesni mladi lidi neznaji historii a nedokazou se z ni poucit nebo ji aplikovat.. a sahaj po trendy resenich, ktere jsou mozna v jedne veci lepsi, ale ve vsech ostatnich horsi. Z programatoru se stavaji lepici kodu, co se bez trendy knihoven a stackoverflow nezmuzou vubec na nic. Ale neplati to jen u programovani.. typicka rodinna situace - dnes varis ty - ... a uz leze na damejidlo.cz a pod :))
Prostě zákon č. 1: V byznysu nevítězí kvalita, ale průměrnost. Geniální myšlenky a teoreticky dobře podložené koncepty z dávných let (70. léta...) jsou dodnes považovány za nereálné vizionářství. Pokrok je diskutabilní, nejvíce času se stráví na vynalézání kola a efektních nesmyslů.
Nicméně kdo kontext zná a má zkušenosti, se může zasadit o to, aby nějakou tu myšlenku napříč generacemi udržel. Neboť na tom je kultura založena a bez toho vpodstatě zaniká.
Ale původní tazatel (nebo klidně někdo jiný) by měl rozvést konkrétní připomínky, proč jsou ty které technologie nevhodné, jinak budeme stejně všichni jen mlátit slámu. Co by třeba ty firmy měly teda použít místo REST a Swagger a co tím získají navíc?
-
V podstatě souhlasím s tím, že REST je vhodný jenom na některé aplikace a rozhodně je nevhodný tam, kde je potřeba RPC. OpenAPI neznám, ale swagger jsem viděl a dospěl jsem k názoru že je to k ničemu.
Nicméně by to celé to kazí ten naprosto zmatený odstavec:
Maly skok do historie. REST byl vyvinuty jako soucast HTTP v roce 1990 a je urcen pro modelovani webovych api typu Resource, tzn. webovka ma nejaky svuj backend, ze ktereho si potrebuje tahat data, zapisovat, updatovat atd. Je to neco designem dost spjateho s HTML, ktere se prenasi pres HTTP v RequestBody at uz pri GET, nebo kdyz se odesila nejaky formular, nebo co ja vim.
No, evidentně jsou u vás programátoři hodně zmateni a ti co si stěžují na rootu jsou akorát jednoocí mezi slepými :-) O správném zařazení primátů do čeledí raději nebudu spekulovat...
Dneska se za valecneho pokriku prumernych opic vyvojaru vytlacuje z backendu SOAP, nadavajic na to, jak je neflexibilni, pricemz se to nahrazuje necim tak naprosto nevhodnym, jako je Swagger api a rest. Samotny REST neni az zase tak problem, i SOAP se prenasi pres HTTP kde metoda je vzdy POST, problem je az teprve Swagger.
No já nevím, vytlačování SOAPu bylo moderní tak před deseti lety - to musí být nějaký extra konzervativní korporát, co? Podle toho co jsem viděl osobně a v Dilbertovi, tak problém je primárně tam :-)
Btw, hidopišská poznámka: SOAP rozhodně nemusí používat HTTP ani POST.
Backendove komponenty mezi sebou potrebuji delat RPC volani a ne si vzajemne sahat do Resource.
Ok, tohle si zaslouží komentář: rozhodně to neplatí všeobecně, existují aplikace kde je "šahání si do Resource" naprosto v pořádku a REST je dobře pasující architektura. Na druhou stranu, existují aplikace kde je to hovadina.
Swagger je navede na to, aby delali Resource API (vetsina ani nevi, co to je), jenze to jim v drtive vetsine pripadu nepasuje na to, co potrebuji delat, coz vsak vedome nevi, takze do toho michaji RPC az nakonec vznkne naprostgo zpackane gulas API.
Kdyz se k tomu prida zaklinadlo OpenAPI a prihodi se rvouci opico-ovce, tak z toho je dalsi jedna velka vyvojarska tragedie, ktera zase pro jednou vede k horsimu a zpackanejsimu backendu.
Clovek by rekl, ze by se mela metodologie vyvoje hybat dopredu, a ne dozadu a jeste dal.
Bohužel, naprosto normální. Pokud ti to vadí, doporučuji změnit obor. Minimálně pak změnit působiště, evidentně to stávající je zbytečně stresující.
Prohlasuju, ze kvuli Swaggeru se enteprise dostal z roku 2019 nekde do stavu vyvoje API pred rokem 2000, nez byl vymyslen SOAP. A to jsem jeste nemluvil o nahrazovani XMLek jinymi, "lepsimi" formaty.
Docela by me zajimal nazor mistnich.
SOAP nebyl první RPC (a to ani první RPC použitelné přes http) a není poslední. Existují jiné varianty, spousta z nich použitelnější, a některé dokonce použitelné v PHP (to je jeden z problémů SOAPu - pokud vím, neexistuje funkční implementace pro PHP).
-
Stejne tak, jako pro IPC komunikaci pouzije zcela nevhodne napr. nanomsg, namisto toho, aby se protokol udelal nad UDP, nebo TCP.
Ok, o nanomsg jsem dodnes neslyšel, ale podíval jsem se na https://nanomsg.org a musím se zeptat: proč je to zcela nevhodné a proč je lepší navrhnout vlastní protokol nad TCP?
Tedy kromě toho, že je to moc nové a že je "trendy" a že je to "lepení" - to já osobně nepovažuji za relevantní argumenty. Pravda, sedmdesátá léta nepamatuji, tak jsem možná jeden z těch "mladých lidí"
-
Nejlepsi byl plan9, vyexportoval si cizi cpu a na nem pustil kod.
co bylo schovane dole programator ani nemusel moc resit (9p).
No tak mame dneska velkou mydlovou operu smichanou z rpc, rest, http, json, soap, a technologii bude pribyvat. Mam pit rum, nebo whisky, nebo pivo?!?
Vratime se k tcp, udp a bajtum?
-
Clovek co nadava na nanomsg, zmq apod a chtel by se vratit k tcp a udp casem zacne vymyslet gigamsg a infinity-mq.
-
Stejne tak, jako pro IPC komunikaci pouzije zcela nevhodne napr. nanomsg, namisto toho, aby se protokol udelal nad UDP, nebo TCP.
Ok, o nanomsg jsem dodnes neslyšel, ale podíval jsem se na https://nanomsg.org a musím se zeptat: proč je to zcela nevhodné a proč je lepší navrhnout vlastní protokol nad TCP?
Tedy kromě toho, že je to moc nové a že je "trendy" a že je to "lepení" - to já osobně nepovažuji za relevantní argumenty. Pravda, sedmdesátá léta nepamatuji, tak jsem možná jeden z těch "mladých lidí"
Najaty programator naprogramoval aplikaci kde je 1 management node, a N slave nodu stylem ze se ten centralni uzel pripojuje skrze nanomsg do klienta a provadi jakysi pokus o RPC. Sakra velky problem je, ze to spojeni navrhnul opacne (protoze dnes je vsecho P2P tak na to co je klient a co server s*re pes vid?), takze moznost pripojit libovolny, predem neznamy pocet uzlu neni mozny. Druhy problem neznalosti sitariny je, ze borec to pseudo RPC mel v blokujicim rezimu pro obe strany. Jako really? A pak to lepi pouzitim X vlaken podle poctu klientu. Dusledek opacne konektivity je, ze namisto dorucovani zprav a normalniho FSM, delal polling, ktery ve spojeni s blokujicim pristupem delal psi kusy a musel dolepovat mutexy. Nemluvne o stavu, kdy jeden klient vypadl, a cely distribuovany system chcipl. Na to, ze UDP by bylo vyhodnejsi pro distribuci broadcast sdeleni, protoze ty uzly se musi synchronizovat a ridit spolecne muzeme taky zapomenout. Co to melo delat bylo znamo predem, ale jak to ma presne udelat nebylo dano. Tak z toho vznikl takovej humus... opravdu neni kazdy hodne programatorske profese.
-
Stejne tak, jako pro IPC komunikaci pouzije zcela nevhodne napr. nanomsg, namisto toho, aby se protokol udelal nad UDP, nebo TCP.
Ok, o nanomsg jsem dodnes neslyšel, ale podíval jsem se na https://nanomsg.org a musím se zeptat: proč je to zcela nevhodné a proč je lepší navrhnout vlastní protokol nad TCP?
Tedy kromě toho, že je to moc nové a že je "trendy" a že je to "lepení" - to já osobně nepovažuji za relevantní argumenty. Pravda, sedmdesátá léta nepamatuji, tak jsem možná jeden z těch "mladých lidí"
Najaty programator naprogramoval aplikaci kde je 1 management node, a N slave nodu stylem ze se ten centralni uzel pripojuje skrze nanomsg do klienta a provadi jakysi pokus o RPC. Sakra velky problem je, ze to spojeni navrhnul opacne (protoze dnes je vsecho P2P tak na to co je klient a co server s*re pes vid?), takze moznost pripojit libovolny, predem neznamy pocet uzlu neni mozny. Druhy problem neznalosti sitariny je, ze borec to pseudo RPC mel v blokujicim rezimu pro obe strany. Jako really? A pak to lepi pouzitim X vlaken podle poctu klientu. Dusledek opacne konektivity je, ze namisto dorucovani zprav a normalniho FSM, delal polling, ktery ve spojeni s blokujicim pristupem delal psi kusy a musel dolepovat mutexy. Nemluvne o stavu, kdy jeden klient vypadl, a cely distribuovany system chcipl. Na to, ze UDP by bylo vyhodnejsi pro distribuci broadcast sdeleni, protoze ty uzly se musi synchronizovat a ridit spolecne muzeme taky zapomenout. Co to melo delat bylo znamo predem, ale jak to ma presne udelat nebylo dano. Tak z toho vznikl takovej humus... opravdu neni kazdy hodne programatorske profese.
Tak asi to dělal poprvé. Možná měl dostat pro začátek menší zadání. Ale s technologií to moc nesouvisí, ne? Ani to automaticky neznamená, že by bylo UDP vhodnější.
-
Tak asi to dělal poprvé. Možná měl dostat pro začátek menší zadání. Ale s technologií to moc nesouvisí, ne? Ani to automaticky neznamená, že by bylo UDP vhodnější.
To ho neomlouva.. zaklady sitariny a BSD socketu by mel mit. Rikam to porad - to, ze nekdo zna jazyk neznamena ze je dobrym spisovatelem. To, ze nekdo zna syntaxi jazyka neznamena ze umi programovat. Jsem z mladejch znechucen. Ale ptat si obri hodinovku, jo to umi.
-
Zaprve je treba si ujasnit, proc chceme dat pryc SOAP. Z meho uhlu pohledu jediny rozumny duvod ktery jsem slysel je, ze se to blbe pouziva treba prave javascriptarum.
Podle me je SOAP v principu genialni a nikdo nevymysli nic lepsiho - tehda moc dobre vymysleli, jak mezi sebou maji backend komponenty komunikovat. SOAP ktery je zalozeny na RPC vlastne vytvari pro programatora ten use case, ze programator jakoby vola metodu v jine komponente a to volani je nezavisle na pouzite platforme.
SOAP zprava prenasena v HTTP je vzdycky POST - vsechny dalsi http metody jsou redundantni. V body se prenasi objekt, jehoz jmeno reprezentuje jmeno metody. Pro rozliseni ma zpravidla postfix "Request". Jeho atributy predstavuji 1:1 parametry metody. A to je v principu co se tyce RPC vsechno - nic vic neni potreba. je zde kompletni, osekana, takrka 1:1 vazba mezi SOAP zpravou a volanou metodou. To co je v REST API delanem jako Resource jsou akorat reduntantni nesmysly:
- HTTP metody - nanic
- path variables - nanic
- jenom jeden mozny request body - nanic
- url parametry - nanic
Je to uplne k nicemu, redundatni nesmysly, ktery oceni tak leda programatory typu impresionisticky umelec, ktery se minul povolanim.
Proc volani mezi komponentami je RPC a resource je nanic? Protoze my takrka vsichni programatori delame v proceduralnim paradigmatu - nepotrebujeme mit jedno paradigma pro programovy kod a jine paradigma pro komunikaci se vzdalenymi komponentami. A nevsiml jsem si, ze by mezi programatorama byl takovy prehrsel borcu, co maji vsechno v maliku, a zvladnou mit v pouzitych technologiich gulas, plny redundtnich kravin. Je to prave naopak.
At uz je programator zalozeny vice OOP nebo vice proceduralne, tak komponenty predstavuji objekty, ktere si mezi sebou posilaji zpravy (volanim metod) uplne stejne, jako kdyz volame v ramci kompinenty nejakou service. Neni tam zadny duvod pouzivat Resource API.
Nevim cim nahradit Swagger API, ale SOAP je v principu pekne a jendoduse nahraditelny a uz jsem to videl:
V prve rade se pouzije uplne stejny princip, jaky pouziva SOAP, protoze nikdo nic lepsiho nevymysli. Pouzije se REST, API se modeluje pomoci XSD, uplatni se uplne stejne pravidla jako ma SOAP:
- vsechny HTTP requesty jsou POST
- sere se z vysoka na path variables a jine kraviny, je tam jen body
- body je XMLko nebo JSON, je to jedno, jeho jmeno predstavuje jmeno metody a atributy jsou 1:1 parametry jakoby parametry metody
- jako bonus se uz zezacatku mysli na zpetnou kompatibilitu pro Response, aby se porad nemuselo verzovat API. K tomu slouzi v XSD tag "<xsd:any ... >" do ktereho se pri prekladu Response na Java objekt nastrkaji do Listu ty atributy, pro ktere se nepodarilo najit zadny konkretni element pro namapovani - takze kdyz se do Response nekdy prida dalsi atribut, tak kvuli tomu nezacnou okolni komponenty padat na hubu.
Neni zde zadny prostor pro impresionisticke umelce programatory, a to je vzycky dobre.
-
A co se tyce toho Swaggeru, tak to v podstate stejne ani nepotrebuju. Kdyz si udelam vhodne XSD soubory, ktere udelam 1:1 ve stylu
jmeno souboru : jmeno tridy (interfacu)
jmeno requestu : jmeno metody
jmena atributu requestu : jmena parametru metody
Tak mam timto jasne definovane API. Jediny problem je, ze toto vyzaduje alespon nejakou minimalni disciplinu a domluvu, a te proste NEJSOU PROGRAMATORI schopni.
-
Jako ja videl swagger jako cestu k vytvoreni snadno udrzovatelne dokumentace k REST API, ve springu (Springfox) se doplnilo jenom par anotaci a byl kod a dokumentace na jednom miste, coz se fajnove reviewuje. API drzelo Resource semantiku (tj GET /cats, GET /cats/1, POST /cats PUT /cats/1, DELETE /cats/1). Jako hlavni problem, na co nadavas, nevidim swagger, ale prave to, ze nekdo prasacky navrhne API. Na Swagger by se dalo jistym zpusobem pohlizet, jako na WSDL pro REST (pomoci obojiho lze vygenerovat kostru kodu)
-
Zaprve je treba si ujasnit, proc chceme dat pryc SOAP. Z meho uhlu pohledu jediny rozumny duvod ktery jsem slysel je, ze se to blbe pouziva treba prave javascriptarum.
Ale to je validný a rozumný dôvod. Angular, React, Vue,.. konzumuje zvyčajne REST API, nie SOAP. Použitie RESTu v komunikácii backend -> JS frontend je správne! Neznásilňuj rokmi overené postupy!
Podle me je SOAP v principu genialni a nikdo nevymysli nic lepsiho - tehda moc dobre vymysleli, jak mezi sebou maji backend komponenty komunikovat.
Jo, na komunikáciu medzi backend komponenty si nechajte SOAP. Javascriptár z frontendu vám nemá čo kecať ako si vy budete komunikovať medzi backend komponenty! A naopak, ak Javascriptár chce na frontend REST tak mu ho dajte a nekecajte mu do jeho práce!
Neni zde zadny prostor pro impresionisticke umelce programatory, a to je vzycky dobre.
Jo, ale impresionistické by bolo posielat chudákovi Javascriptarovi SOAP, tam frčí REST!
-
Tak asi to dělal poprvé. Možná měl dostat pro začátek menší zadání. Ale s technologií to moc nesouvisí, ne? Ani to automaticky neznamená, že by bylo UDP vhodnější.
To ho neomlouva.. zaklady sitariny a BSD socketu by mel mit.
Jistě. Všechno co udělal by udělal úplně stejně blbě s BSD sockety. Takže nanomsg je v to úplně nevinně.
Já vím že je se to dá brát jako šťourání, ale sorry - bavíme se zde o schopnosti lidí analyticky řešit problémy, a takové detaily jako správná identifikace zdroje problémů, jsou zásadní.
-
SOAP zprava prenasena v HTTP je vzdycky POST - vsechny dalsi http metody jsou redundantni. V body se prenasi objekt, jehoz jmeno reprezentuje jmeno metody. Pro rozliseni ma zpravidla postfix "Request". Jeho atributy predstavuji 1:1 parametry metody. A to je v principu co se tyce RPC vsechno - nic vic neni potreba. je zde kompletni, osekana, takrka 1:1 vazba mezi SOAP zpravou a volanou metodou. To co je v REST API delanem jako Resource jsou akorat reduntantni nesmysly:
Je to uplne k nicemu, redundatni nesmysly, ktery oceni tak leda programatory typu impresionisticky umelec, ktery se minul povolanim.
Sorry, ale zase mimo. Když pomineme to že jsou i jiné transportní možnosti než HTTP (moc se to nevidí), tak rozhodně nemůžeme vynechat dva různé styly - RPC a Document. V kombinaci s literal/ecoded to dává čtyři styly. No a pak samozřejmě haldy různých rozšíření. A to že přenos přes HTTP není úplně přesně standardizován, takže ne každé dvě implementace se domluví (ok, možná že v tomhle se situace za posledních 15 let změnila). Jo, hlavička SOAPAction, s tou byl vždy kopec srandy...
To co popisuješ je v podstatě XML-RPC, nebo gRPC, nebo některý z dalších protokolů - už jsem jich viděl víc. Ale rozhodně ne SOAP.
Neni zde zadny prostor pro impresionisticke umelce programatory, a to je vzycky dobre.
V SOAPu je hodně prostoru pro manýristické umělce programátory. To je hlavní důvod, proč se proti němu před deseti lety zvedla vlna odporu. Dnes se možná zvedná vlna odporu proti RESTu, uvidíme co bude dál.
Holt musím pověsit cibule na opasek a dát za pravdu RDa: Dneska ti mladí neznají historii...
-
U jednodussich aplikaci je navrh API odshora overkill. Lepsi vychazet z ORM modelu.
-
Stejne tak, jako pro IPC komunikaci pouzije zcela nevhodne napr. nanomsg, namisto toho, aby se protokol udelal nad UDP, nebo TCP.
Ok, o nanomsg jsem dodnes neslyšel, ale podíval jsem se na https://nanomsg.org a musím se zeptat: proč je to zcela nevhodné a proč je lepší navrhnout vlastní protokol nad TCP?
Tedy kromě toho, že je to moc nové a že je "trendy" a že je to "lepení" - to já osobně nepovažuji za relevantní argumenty. Pravda, sedmdesátá léta nepamatuji, tak jsem možná jeden z těch "mladých lidí"
Najaty programator naprogramoval aplikaci kde je 1 management node, a N slave nodu stylem ze se ten centralni uzel pripojuje skrze nanomsg do klienta a provadi jakysi pokus o RPC. Sakra velky problem je, ze to spojeni navrhnul opacne (protoze dnes je vsecho P2P tak na to co je klient a co server s*re pes vid?), takze moznost pripojit libovolny, predem neznamy pocet uzlu neni mozny. Druhy problem neznalosti sitariny je, ze borec to pseudo RPC mel v blokujicim rezimu pro obe strany. Jako really? A pak to lepi pouzitim X vlaken podle poctu klientu. Dusledek opacne konektivity je, ze namisto dorucovani zprav a normalniho FSM, delal polling, ktery ve spojeni s blokujicim pristupem delal psi kusy a musel dolepovat mutexy. Nemluvne o stavu, kdy jeden klient vypadl, a cely distribuovany system chcipl. Na to, ze UDP by bylo vyhodnejsi pro distribuci broadcast sdeleni, protoze ty uzly se musi synchronizovat a ridit spolecne muzeme taky zapomenout. Co to melo delat bylo znamo predem, ale jak to ma presne udelat nebylo dano. Tak z toho vznikl takovej humus... opravdu neni kazdy hodne programatorske profese.
Abych to shrnul, nanomg je spatne, protoze to nejaky jouda spatne pouzil, proto budeme pro broadcast messages pouzivat UDP pakety, u kterych neni jistota ze vubec dojdou, o nedoruceni se nikdo nedozvi, koncept postavime na uporne vire, ze UDP paket zkratka dojde. Nebo budem UDP pakety potvrzovat ja u blbych a naimplementujem si vlastni TCP stack pro chude.
Hlavne nepouzit neco jako NATS, ktery je na tyhle ulohy delany.
-
Zaprve je treba si ujasnit, proc chceme dat pryc SOAP. Z meho uhlu pohledu jediny rozumny duvod ktery jsem slysel je, ze se to blbe pouziva treba prave javascriptarum.
Podle me je SOAP v principu genialni a nikdo nevymysli nic lepsiho - tehda moc dobre vymysleli, jak mezi sebou maji backend komponenty komunikovat. SOAP ktery je zalozeny na RPC vlastne vytvari pro programatora ten use case, ze programator jakoby vola metodu v jine komponente a to volani je nezavisle na pouzite platforme.
SOAP zprava prenasena v HTTP je vzdycky POST - vsechny dalsi http metody jsou redundantni. V body se prenasi objekt, jehoz jmeno reprezentuje jmeno metody. Pro rozliseni ma zpravidla postfix "Request". Jeho atributy predstavuji 1:1 parametry metody. A to je v principu co se tyce RPC vsechno - nic vic neni potreba. je zde kompletni, osekana, takrka 1:1 vazba mezi SOAP zpravou a volanou metodou. To co je v REST API delanem jako Resource jsou akorat reduntantni nesmysly:
- HTTP metody - nanic
- path variables - nanic
- jenom jeden mozny request body - nanic
- url parametry - nanic
Je to uplne k nicemu, redundatni nesmysly, ktery oceni tak leda programatory typu impresionisticky umelec, ktery se minul povolanim.
Proc volani mezi komponentami je RPC a resource je nanic? Protoze my takrka vsichni programatori delame v proceduralnim paradigmatu - nepotrebujeme mit jedno paradigma pro programovy kod a jine paradigma pro komunikaci se vzdalenymi komponentami. A nevsiml jsem si, ze by mezi programatorama byl takovy prehrsel borcu, co maji vsechno v maliku, a zvladnou mit v pouzitych technologiich gulas, plny redundtnich kravin. Je to prave naopak.
At uz je programator zalozeny vice OOP nebo vice proceduralne, tak komponenty predstavuji objekty, ktere si mezi sebou posilaji zpravy (volanim metod) uplne stejne, jako kdyz volame v ramci kompinenty nejakou service. Neni tam zadny duvod pouzivat Resource API.
Nevim cim nahradit Swagger API, ale SOAP je v principu pekne a jendoduse nahraditelny a uz jsem to videl:
V prve rade se pouzije uplne stejny princip, jaky pouziva SOAP, protoze nikdo nic lepsiho nevymysli. Pouzije se REST, API se modeluje pomoci XSD, uplatni se uplne stejne pravidla jako ma SOAP:
- vsechny HTTP requesty jsou POST
- sere se z vysoka na path variables a jine kraviny, je tam jen body
- body je XMLko nebo JSON, je to jedno, jeho jmeno predstavuje jmeno metody a atributy jsou 1:1 parametry jakoby parametry metody
- jako bonus se uz zezacatku mysli na zpetnou kompatibilitu pro Response, aby se porad nemuselo verzovat API. K tomu slouzi v XSD tag "<xsd:any ... >" do ktereho se pri prekladu Response na Java objekt nastrkaji do Listu ty atributy, pro ktere se nepodarilo najit zadny konkretni element pro namapovani - takze kdyz se do Response nekdy prida dalsi atribut, tak kvuli tomu nezacnou okolni komponenty padat na hubu.
Neni zde zadny prostor pro impresionisticke umelce programatory, a to je vzycky dobre.
A ted jak je to v realite.
Prijdu u zakaznika k jeho SOAP service.
Totalni chaos a bordel, veschny atributy vystaveny nako optional String. Beda ale kdyz onen optional string nevyplnim, vrati se mi SOAP exception s payload "Eror-11355 - Bus error".
Dostanu WSDL, pro ktery si mam vygenerovat skeleton. Vsechny datove polozky se jmenujou "data" a pouzivanji WSDL s indcludouvanym XSD, co ma includovany XSD, co ma includovany XSD. Nejlepe nejaky business celofiremni header, co odkazuje na nejake dalsi XSD, nejlepe tak kouzelne provazano, ze cely balik provazanych XSD ma 30 mega, vsechno kolem toho chodi a boji se do toho sahnout.
Pak udelam zakladni jednoduchy Spring client, ktery si vzdy na zacatku vyrobi z WSDL skeleton callu, springovi pak trva priprava na kazdy WS call 4 sekundy na 8jadrovem serveru. Tak si jak u blbejch implementuju pool predpripravenych clientu a reusuju.
Konkretne onen 30MB bulk mej i tu vlastnost, ze jediny, kdo byl schopen pro to vygenerovat skeleton byl priohly SpringWS za pouziti wsimport, JAXB nelepil vubec, ten lehl rovnou pri generovani.
Pak prijde pozadavek za zabezpeceni. Mrknu se na WSsecurity extenze a zjistim, ze tohle narhoval naprosty magor. Ze jakmu jsem si nasel autory navrhu, tri panove ze Microsoftu/Sunu/Ericssonu. Napriklad existuje 7 zpusobu predavabi verejneho klice, koncept je tak brutalne slozity, ze prakticky neexistuje plna implementace vseho.
Finalne po cca mesici prace (nedelam si zadek) se "zabezpecene" pripojim, request ma celkem 7 KB z toho payload je jeden bajt "0" nebo "1".
Vse co popisuju jsem realne zazil a ty systemy stale "funguji".
SOAP je v realnem pouziti prekomplikovany shit a proto taky vsechny softy co znam vystavujou API na REST nebo XML-RPC.
-
Vse co popisuju jsem realne zazil a ty systemy stale "funguji".
SOAP je v realnem pouziti prekomplikovany shit a proto taky vsechny softy co znam vystavujou API na REST nebo XML-RPC.
Přidávám se, moje zkušenosti jsou velmi podobné.
Na druhou stranu předpokládám, že přesně takhle budou vypadat korporátní systémy budované pomocí Swaggeru (podle toho co píše OP, tak mají dobře našlápnuto).
-
A ted jak je to v realite.
Prijdu u zakaznika k jeho SOAP service.
Totalni chaos a bordel, veschny atributy vystaveny nako optional String. Beda ale kdyz onen optional string nevyplnim, vrati se mi SOAP exception s payload "Eror-11355 - Bus error".
Dostanu WSDL, pro ktery si mam vygenerovat skeleton. Vsechny datove polozky se jmenujou "data" a pouzivanji WSDL s indcludouvanym XSD, co ma includovany XSD, co ma includovany XSD. Nejlepe nejaky business celofiremni header, co odkazuje na nejake dalsi XSD, nejlepe tak kouzelne provazano, ze cely balik provazanych XSD ma 30 mega, vsechno kolem toho chodi a boji se do toho sahnout.
Pak udelam zakladni jednoduchy Spring client, ktery si vzdy na zacatku vyrobi z WSDL skeleton callu, springovi pak trva priprava na kazdy WS call 4 sekundy na 8jadrovem serveru. Tak si jak u blbejch implementuju pool predpripravenych clientu a reusuju.
Konkretne onen 30MB bulk mej i tu vlastnost, ze jediny, kdo byl schopen pro to vygenerovat skeleton byl priohly SpringWS za pouziti wsimport, JAXB nelepil vubec, ten lehl rovnou pri generovani.
Pak prijde pozadavek za zabezpeceni. Mrknu se na WSsecurity extenze a zjistim, ze tohle narhoval naprosty magor. Ze jakmu jsem si nasel autory navrhu, tri panove ze Microsoftu/Sunu/Ericssonu. Napriklad existuje 7 zpusobu predavabi verejneho klice, koncept je tak brutalne slozity, ze prakticky neexistuje plna implementace vseho.
Finalne po cca mesici prace (nedelam si zadek) se "zabezpecene" pripojim, request ma celkem 7 KB z toho payload je jeden bajt "0" nebo "1".
Vse co popisuju jsem realne zazil a ty systemy stale "funguji".
SOAP je v realnem pouziti prekomplikovany shit a proto taky vsechny softy co znam vystavujou API na REST nebo XML-RPC.
Tak. A je to tu. A tohle je urcite duvod k tomu, proc pouzivat REST. Ze to nekdo zprasil. Ti sami lidi zprasi i ten REST!
-
Zprasit se da vzdycky a vsechno. Touto logikou bys nevytvoril nic
-
Zprasit se da vzdycky a vsechno. Touto logikou bys nevytvoril nic
No samozrejme, ze se da zprasit vsechno, pak nema smysl sasit s prekoplikovanym WSDL selmostrojem, kdyz mi staci jednoduchy XML-RPC over HTTPS a zabezpeceni spring-security poveseny na Url pattern.
Ws security extensions je ciste dilo blaznovo, ti tri magori, co to navrhovali, se u toho museli smat jak Joker z Batmana.
Wsdl.se.da navrhnout bud striktne, pak je to straslive neohebne a da se na ro realne napojit jenom z Jawy a castecne z C#. Nebo se WSDL definuje jako shluk optional stringu, pak se na to da napojit i s PHP, Perlu - na nejake checky konzistence dat sozrejme zapomen.
Kdyz uz mam sasit s pevne definovanou strukturou zprav, to uz radri nasadim ProtocolBuffers - to ma aspon vykon.
-
Ale tu nie je reč o moderných web aplikáciách, že nie? Lebo inak by ste boli ale fakt, že zúfalo mimo a možno až 20 rokov pozadu.
-
Ale tu nie je reč o moderných web aplikáciách, že nie? Lebo inak by ste boli ale fakt, že zúfalo mimo a možno až 20 rokov pozadu.
Moderni web appka ktera neni schopna fungovat na 2 roky starem prohlizeci, jo, to vis, ze to potrebuji jako uzivatel ke spokojenosti (konkretne Aukro.cz nejede uz pres rok, na FF 45.x vydanem 2016/03). Nyni se pridavaji MAPY.cz - ale jenom nekdy. Zda se ze includovane mapky na webech porad funguji.. ale jejich hlavni stranka nikoliv. To je pokrok, jo?
-
Standa Blabol:
Co je spatneho na WSDL co ma include XSD a dalsi a dalsi? To WSDL se prece da vygenerovat na zaklade XSD schematu. Ty ho pak pouzijes pro SOAP UI nebo pro vygenerovani Clienta. To te prce nemusi moc zajimat, co v tom WSDL presne je, nemusis si ho cist. Ne snad?
-
Standa Blabol:
Co je spatneho na WSDL co ma include XSD a dalsi a dalsi? To WSDL se prece da vygenerovat na zaklade XSD schematu. Ty ho pak pouzijes pro SOAP UI nebo pro vygenerovani Clienta.
kdyz ti nevadi, ze zbytecne posilas tuny sracek. Treba u mobilnich aplikace to muze vadit.
To te prce nemusi moc zajimat, co v tom WSDL presne je, nemusis si ho cist. Ne snad?
jen dokud vse funguje.
-
To te prce nemusi moc zajimat, co v tom WSDL presne je, nemusis si ho cist. Ne snad?
Když je něco pod povrchem fuj, tak se to časem projeví. Konkrétně sprasené WSDL nemusí fungovat v háklivějších klientech, např. v PHP. Pak se to narovnávákem na ohejbák nějak rozchodí, ale radost ani dobrá vizitka to není...
-
Standa Blabol:
Co je spatneho na WSDL co ma include XSD a dalsi a dalsi? To WSDL se prece da vygenerovat na zaklade XSD schematu. Ty ho pak pouzijes pro SOAP UI nebo pro vygenerovani Clienta.
kdyz ti nevadi, ze zbytecne posilas tuny sracek. Treba u mobilnich aplikace to muze vadit.
To te prce nemusi moc zajimat, co v tom WSDL presne je, nemusis si ho cist. Ne snad?
jen dokud vse funguje.
Omg co to zas je za kec, jake tuny sracek, posilas jen XMLko s daty, oproti XSD schematu se to jen validuje. Muzes to poslat i jako JSON.
-
To te prce nemusi moc zajimat, co v tom WSDL presne je, nemusis si ho cist. Ne snad?
Když je něco pod povrchem fuj, tak se to časem projeví. Konkrétně sprasené WSDL nemusí fungovat v háklivějších klientech, např. v PHP. Pak se to narovnávákem na ohejbák nějak rozchodí, ale radost ani dobrá vizitka to není...
Zaprve, kdyz se to WSDL vygeneruje automaticky na zaklade XSD schematu, tak by si s tim snad melo poradit PHP pri generovani clienta. Zadruhe kdyz si s tim neporadi, tak je to uplne jedno, protoze jako predloha stejne slouzi to XSD schema - to je v podstate primarni human readble API te aplikace - a s tim uz si snad musi poradit PHP nebo programator, aby si na zaklade schematu udelal request. Zatreti, kdyz si ani s timto neporadi, tak at de dozadeke, radeji nekde na salas past ovce.
-
Zaprve, kdyz se to WSDL vygeneruje automaticky na zaklade XSD schematu, tak by si s tim snad melo poradit PHP pri generovani clienta.
Mělo. Podmiňovací způsob je na místě.
Co mě ale zaráží víc, je (opakované) tvrzení že WSDL se generuje automaticky na základě XSD schématu. Což je naprostý nesmysl - WSDL obsahuje XSD pro definici typů, ale obsahuje i spoustu dalších informací které v XSD nejsou. Viděl jsi WSDL vůbec někdy?
A to ani nemluvím o WSDL 1.1, které se pokud vím stále ještě leckde vyskytuje.
Zadruhe kdyz si s tim neporadi, tak je to uplne jedno, protoze jako predloha stejne slouzi to XSD schema - to je v podstate primarni human readble API te aplikace - a s tim uz si snad musi poradit PHP nebo programator, aby si na zaklade schematu udelal request. Zatreti, kdyz si ani s timto neporadi, tak at de dozadeke, radeji nekde na salas past ovce.
Ano, tak to také dopadne. A pak si někdo vzpomene, že se použije pro WS-Security pro zabezpečení...
Omg co to zas je za kec, jake tuny sracek, posilas jen XMLko s daty, oproti XSD schematu se to jen validuje. Muzes to poslat i jako JSON.
SOAP přes JSON? Tak to jsem ještě neslyšel. Což se může stát, novinky nesleduji, možná komise vytvořila nové monstrum, nebylo by to poprvé. Na druhou stranu, uvážím-li kvalitu ostatních informací, může to být jen blábol.
Takže: Můžeš sem dát odkaz na specifikaci?
-
Ja to nechápem... O čom je tu reč? Prečo má byť Swagger či OpenAPI zlé? Lebo nepoužíva staršie formáty? A prečo by malo, keď funguje v pohode tak, ako je navrhnuté? Prečo to tu vôbec motáte dohromady? Utter crap sú tu väčšinou práve takéto témy. Ktoré produkujú skostnatení programátori v návale frustrácie zo zistenia, že veci ktoré sa naučili 20 rokov dozadu sú im dnes hovno platné a zamestnávatelia / zákazníci po nich chcú nové architektúry. Na jednej strane to chápem. Ale na druhej strane len idiot čo si nedovidí ďalej od nosa, sa môže verejne vyplakávať nad tým, že sa veci v čase menia a dozrievajú. Ani to večné povyšovanie sa a vyplácanie, že im mladí, ktorí ani náhodou nemajú tak rozsiahle znalosti tématiky, berú prácu. Už sa ukľudnite. Plač nepomôže. DOKÁŽTE, že je lepšie to, čo tvrdíte. Ukážte mi v praxi ako rýchlejšie a lacnejšie napíšete client / server apku bez OpenAPI a napríklad Vue. Lebo TO by zavážilo (lebo to nie je podľa mňa možné) a nie to vyplakávanie a machrovanie akí ste skvelí programátori a ostatní sú odpad. Lebo akokoľvek ste skvelí, vyzerá to, že zároveň ste v dnešnej praxi nepoužiteľní...
-
Zaprve, kdyz se to WSDL vygeneruje automaticky na zaklade XSD schematu, tak by si s tim snad melo poradit PHP pri generovani clienta.
Mělo. Podmiňovací způsob je na místě.
Co mě ale zaráží víc, je (opakované) tvrzení že WSDL se generuje automaticky na základě XSD schématu. Což je naprostý nesmysl - WSDL obsahuje XSD pro definici typů, ale obsahuje i spoustu dalších informací které v XSD nejsou. Viděl jsi WSDL vůbec někdy?
A to ani nemluvím o WSDL 1.1, které se pokud vím stále ještě leckde vyskytuje.
Zadruhe kdyz si s tim neporadi, tak je to uplne jedno, protoze jako predloha stejne slouzi to XSD schema - to je v podstate primarni human readble API te aplikace - a s tim uz si snad musi poradit PHP nebo programator, aby si na zaklade schematu udelal request. Zatreti, kdyz si ani s timto neporadi, tak at de dozadeke, radeji nekde na salas past ovce.
Ano, tak to také dopadne. A pak si někdo vzpomene, že se použije pro WS-Security pro zabezpečení...
Omg co to zas je za kec, jake tuny sracek, posilas jen XMLko s daty, oproti XSD schematu se to jen validuje. Muzes to poslat i jako JSON.
SOAP přes JSON? Tak to jsem ještě neslyšel. Což se může stát, novinky nesleduji, možná komise vytvořila nové monstrum, nebylo by to poprvé. Na druhou stranu, uvážím-li kvalitu ostatních informací, může to být jen blábol.
Takže: Můžeš sem dát odkaz na specifikaci?
XSD schematem si definuju, jak ma vypadat API, tzn. jake maji mit nazvy metody, a podle nazvu souboru toho xsd si definuju i tridy metod. Potom si z XSD vygeneruju Java classy. Ve Springu muzu nyni pouzit budto dle JAX-RS nebo JAX-WS udelam enpoint tridy, ktere cti jmennou konvenci definovnou tim XSD.
Pokud pouziju JAX-WS, tak na zaklade tech trid mi umi Spring automaticky vygenerovat i WSDL soubory. Pokud ale volam jinou komponentu, tak me jeji WSDL vubec nezajima - k tomu abych si ji zavolal potrebuju znat jen 2 veci: url a XSD schema.
Proto rikam, ze XSD me slouzi jako API komponenty, nepotrebuju na to pitomy Swagger. Mam z XSD vygenerovane Javovoske tridy a na zaklade jejich jmen a popisu vim, co je to za metody, treba hned vim, co bude delat: com.xsdforever.violence.DeleteSwaggerFromGalaxy.java
Pokud ale pouzije JAX-RS pro endpoint a udelam to jako rpc, tak muzu porad pouzit XSD jako predlohu, nacez muzu samozrejme pak posilat i JSON zpravy - na tom nesejde, protoze JSON se da validovat oproti XSD.
-
...
Takže, abych to shrnul - vy vlastně ani WS/SOAP nepoužíváte. Vy jenom používáte podmnožinu konkrétní implementace v Javě pro "homemade" RPC.
No, v podstatě proč ne. Když vám to funguje, tak na tom není nic špatného. Výhody jsou jasné - do životopisu a powerpoint slajdů pro management si dáte spoustu pěkných zkratek a přitom se nemusíte skutečně zabývat radostmi standardu vyprodukovaného komisí složenou z těch nejbyrokratičtějších korporací v oboru.
JSON se da validovat oproti XSD
Jo, a v Sovětském Svazu rozdojili kozla...