Samozrejme ze jde.
Jenze alespon ty dva elementy vedou k nejakemu standardnimu postupu, coz je stale lepsi, nez kdyz nemam naprosto nic. Typicky serverova strana, alespon v pripade SOAPu a normalnich vyvojovych nastroju vyvojare nuti tyhle konvence pouzivat.
Coz typickeho weboveho kodera co udela svym ajaxovym stylem "API" pro ostatni ani nenapadne. Uz proto, ze ho k tomu nic nenuti.
Co přesně znamená, že "SOAP fault má naprosto jasně definované elementy Code a Reason"? Znamená to, že mám jako klient jistotu, že se mi nevrátí Code Server a Reason "hmmm, vypadá to, že se nám tu něco rozbilo", což je na úrovni toho OK/Error (a navíc se tento kód vrátí, i když jde o Client fault)? Opravdu to takhle nejde zprasit? A co přesně v tom někomu zabrání?
Nejde, SOAP fault ma naprosto jasne definovane elementy Code a Reason. Zatimco REST je zcela nedefinovany a ve vetsine pripadu bude rozliseni jen OK a error, bez niceho dalsiho.
Ohledne elementu Detail, viz dalsi odpoved, ten muze obsahovat jiz predem nedefinovanou strukturu (typicky vyjimku) ze serveru. To ovsem neni nic podle ceho by se mel jaykoli klient ridit, od toho jsou prave ty dva elementy vyse.
Sorry, ale pises nesmysly. Vubec jsi nepochopil rozdil mezi SOAPem a RESTem. REST s JSON nema vubec nic spolecneho. REST narozdil od SOAPu definuje jenom zpusob komunikace, ale ne to v jakem formatu se budou informace prenaset. v RESTu se samozrejme pouzivat XML. A v cem je problem, ze WADL neni standardizovane? To, ze narazis na nekoho, kdo to dela resp. ma blbe ale neni problem technologie. Takhle se da rict, ze ty tomu fakt nerozumis take.
Tohle je proste naprosty nesmysl! Asi bys mel neco RESTu resp. o HTTP nastudovat, to ze vratis chybovy kod totiz jeste neznamena, ze nemuzes vratit zpravu proc k tomu doslo v tele zpravy. To, ze to nejaky patlal zprasil a udelal to nedomyslene ale neni problem RESTu. Stejne to jde zprasit i v SOAPu.
Jenze WADL skoro nikdo nepodporuje a neni rozhodne standardni zalezitost.
Stejne tak opacne, za celou dobu jsem videl pouze jednoho PHP programatora co umel pouzit WSDL tak, ze z neho vygeneroval tridy s metodami a parametry (coz je dukaz, ze to v PHP jde). Zbytek sestavoval (patlal) xml message jako string po radcich podle prikladu metodou pokus/omyl, takze napriklad datum vubec neodpovidal ISO 8601 atd. Zrejme zvyk z RESTu :-/
Zkratka tohle cely obor vraci o nejakych deset, patnact let zpet. Uz prisli na to ze v RESTu chybi schema, pak prijdou na to ze tam chybi i jmenne prostory atd. Nakonec znovu objevi cele XML, jen proto ze mu dodnes nerozumi.
REST a JSON zkratka nejsou vhodne technologie na obecne API a volani sluzeb napric ruznymi systemy. Ano, daji se tak zneuzit, ovsem vysledek podle toho vypada.
Ani toto neni prilis korektni argument. Patlalove s RESTem, kteri nedodrzuji elementarni RESTful pravidla sice zpusobuji podobne situace, ale ze by se nedaly vyjimky serializovat napriklad na 3xx/4xx/5xx navratove stavy, tak o tom by se mohlo velmi dlouze polemizovat.
Ramcove ovsem mate zajiste pravdu, pokud potkate Windows-only mladika s REST slovnikem, tak podle mych zkusenosti v pomeru 20:1 vytvori presne co popisujete. Ovsem to je spise jeho schopnostmi nez technologii...coz neni v IT zase tak neobvykla situace.
Jeste k tem uzasnym stavum, tohle me vzdy pobavi. Ty jsou stylem ok nebo error. Pokud bych ovsem chtel vedet detail proc k dane chybe doslo a nejak na ni reagovat, tak rest samozrejme konci.
Zatimco SOAP ma na toto jednoznacny mechanismus (SOAP fault), kde si vsechny stavy muzete definovat a jeste klientovi poskytnout naprosto presnou informaci proc k dane chybe doslo.
Ja vim, zni to jak z jine planety a neresi se pritom tyden, v jakem formatu se posila datum, protoze to nebylo v prikladu pokus/omyl :-)
Ne, tohle rozhodne zadny cas ani prostredky pri vyvoji nesetri. To jej spise naprosto vylucuje, tedy pokud ma mit nejaky pouzitelny a testovatelny vysleedek.
Celý vývoj aplikace založený na RESTu je mnohem levnější.
Aha, takze tydny matlat volani stylem pokus/omyl je levnejsi, nez za dve vteriny vytvorit z WSDL klientsky kod, kterym lze vse bezproblemove volat. No jeste dalsi pohadku prosim.
REST je neco jako kalkulacka versus pocitac, oboje ma svuj ucel, ale neni zastupitelne.
Zvyknete si rest/js/php patlalove, co nicemu jinemu nerozumite :-)
Asi proto, že SOAP je totálně mrtvý kvůli své pomalosti a těžkopádnosti. REST založený na JSON je mnohonásobně jednoduší a poskytuje obrovskou paletu stavů v HTTP protokolu. Celý vývoj aplikace založený na RESTu je mnohem levnější. Tak asi proto. PS: Zvykněte si JAVA/C# fans ;)
No, jestli si transakce necháváte posílam e-mailem, tak nějaký přímý přístup bez vašeho souhlasu na tom už nic moc nezhorší, ne?
Neexistence rozumného rozhraní vskutku noční můra, snad ta nová regulace EU ohledně public API něco zlepší i pro domácí kutily (finanční data do cloudu, to se mi nezdá).
Zatím to řeším v GnuCash, data sbírám z Androidí appky (hotovost) a z bank či kreditních karet (ofxstatement se zdá býti dobrou cestou, ale ještě jsem se nedostal k napsání pluginů).
GnuCash se učí typy transakcí, na kreditce po pár měsících rozezná kolem 80 % opakujících se výdajů.
Nicméně nutnost importu přes GUI v GnuCash je otrava (File / Import / CSV / click + click + click / Next / Next / Next ...) Když má člověk více účtů, je to ke zblbnutí.
Cože?
Fakt, že zjišťují informace z transakčních e-mailů chápu, to mi přijde normální. Že je to potřeba nastavit u uživatele mi taky přijde normální.
Ale v rozhovoru zmíněná informace, že existují nějací prostředníci, kteří jsou napojení na banky napřímo a mají data o účtech klientů, aniž by klient složitě něco nastavoval, to mě tedy šokovalo!
V mojí bance mi tedy nic takového nikdy neřekli a žádný souhlas k podobné pitomosti jsem nedával! Co to má být?