Continuing the discussion from Pripomienkovanie CSRU:
V backendovom svete je to prirodzene. JSON ma zmysel pre sluzby, ktore su vystavene pre frontend. Ale to potom asi nebude komunikacia MEDZI roznymi systemami, ale medzi (frontend) klientom a (backend) serverom toho isteho IS.
(?)
Ve světě SaaS je docela běžné, že se REST + JSON API používá jak pro komunikaci s klientem, tak i serverem. Dokonce služby, co podporovaly XML postupně tuto podporu ruší ve prospěch JSON. (Primární důvod je jednodušší práce v programovacích jazycích a tedy pokud bylo na výběr, tak XML skoro nikdo nepoužíval.)
Nejlepší zkušenost s API (z pohledu DX - developer experience) mám s FB:
Jan Pobořil
http://honza.poboril.cz/
smime.p7s (2.31 KB)
soap a xml stale patri do business sveta, je to samopopisne a jednoznacne. rest je naproti tomu prisil volny a vela ludi to robi po svojom a neponuka nastroje na konzistenciu, potom vznikaju veci ako json-schema.org alebo HATEOAS na riesenie problemov ktore uz soap ma vyriesene v zaklade. to je ako java vs javascript.
ws-* maju svoje opodstatnenie a su realne vyuzitelne ale netreba to prehanat (napr enkryptovanie sprav sa da robit cez transport vacsinou ) atd.
rest mi prijde vhodnejsi pre interne potreby aplikacie alebo zakladny pristup k logike a datam a soap pre vsetko ostatne
Zaujimave. Lebo podla vynosu je to presne naopak 
Pre open data je mozne pouzivat aj REST a SOAP pre vsetko ostatne. 55/2014 Z.z. - Výnos Ministerstva financií Slovens... - SLOV-LEX
WS ja vnimam historicky, ale v principe je to takmer uplne jedno. Format ako format - dolezite su data a volania. REST je pristupnejsi pre pochopenie clovekom v surovom stave, ale tooling a standardizacia tam chyba. Nieco za nieco.
Nie moc stastne som sa vyjadril, rest je dobry na lahky pristup k datam a jednoduchym funkciam ako vytvorit a ulozit. Na vsetko len o kusok zlozitejsie (sso, vyuzitie v orchestracii, asynchronne sluzby, rozne kanaly, atd…) mi prijde vhodnejsi soap. Netvrdim, ze sa to neda cez rest ale je to narocnejsie a treba vymyslat veci nanovo (to riesia prave tie ws-* pre soap) co je zdroj chyb a nejasnosti + treba sikovnejsich ludi aby to bolo uspesne vo vacsom projekte.
Mne osobne sa osvedcilo ked su integracie jednotne (soap) ako jednoduchost prveho pouzitia (rest). Aj ta jednoduchost nie je vzdy na mieste, minule kolega prerabal jednu integraciu zo soap do rest, soapove volanie mal davnejsie v c# hotove za 10minut, a s restovym sa trapil 1 den + komunikacia navyse s dodavatelom.
SOAP je minulosť, ktorá vznikla v podstate v minulom tisícročí, keď JSON ani neexistoval a všetko sa riešilo v XML. Má samozrejme svoje výhody. Ale keď si pozriete nové programovacie jazyky (D, Rust, Go, Swift), tak v nich urobiť SOAP komunikáciu je utrpenie, pretože chýba akákoľvek podpora.
vyskladat soap request nie je vobec zlozite a uz vobec nie ho precitat, ved je to obycajne xml s par pravidlami navyse. teda ak sa nebavime o extensionoch ale ked vyzadujes taku funkcionalitu co maju extenstions od rest tak to musis vymyslat nanovo.
v minulom tisicroci vzniko c, javascript, unix, http a vela veci a nepovazujem ich za zbytocne alebo zastarale.
b2b ma ine potreby ako b2c, vidim miesto pre soap aj rest, jedno univerzalne kladivo na kazde pouzitie je zly napad.
A kto by chcel v tych jazykoch robit b2b?
SOAP ma svoje opodstatnenie - mas datove struktury, ktore maju definovanu strukturu, datove typy atributov, a dokumentaciu (XSD). Ak je to dobre navrhnute, daju sa reusovat, a data (XML) ako aj definicie (XSD) strojovo spracovavat. Ktora (velka, enterprise) databaza poskytuje data v JSONe? A ktora v XML/SOAP? Preco asi?
V súčasnosti pomerne veľa IS prechádza na model microservisov a rôznych NoSQL databáz. Často sa miešajú rôzne technológie aj v pomerne malých projektoch. Väčšinou sa potom použije REST a JSON, pretože to podporujú rôzne tooly, rôzne jazyky.
Ale v princípe to nie je tak dôležité, či SOAP alebo REST. Je to len minoritná otázka.
Ci REST alebo SOAP je otazka preferencii, nie technologie. Obe vieme obkodovat v kazdom popularnejsom jazyku. Otazka by mala byt postavena, v com sa bude developerom lepsie robit a co viac poznaju (XML tu je dlhsie a je na legacy systemoch, JSON je poslednych x rokov neskutocne v popredi).
koniec koncov to je naozaj okrajova otazka imo
Ked je dobre navrhnuta architektura systemu, nie je takmer ziadny problem podporovat viacere I/O formaty naraz s minimalnymi dodatocnymi nakladmi, napriklad JSON aj XML, pripadne tiez CSV, pre exporty PDF, atd. Takto to podporuju niektore systemy ktore pouzivame, aj informacny system ktory vyvijame. Raz sa to musi dobre vymysliet a potom to uz ide samo.
to je pravda, ale tu skor rozoberali skor biznis problem, z casti legislativny a z casti styl prace… po technickej stranke nie je problem implementovat viac rozhrani lebo vacsinou su to len obalene volania do servisnej vrstvy
