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.