Amikor a hupuk győznek...

Volt egy olyan, hogy SOAP. Volt sok hibája, de alapvetően működött, behúztam a WSDL-t a <randomide>-ben, legenerált mindent, és a legenerált osztályokból látszott, hogy mi mozog milyen irányba.

Aztán jöttek a hupuk, jött a "megváltás": RESTful service meg babámkínja és TADA megszületett az ASP.NET Web API. Most mi van? Háááát, fogj egy Fiddlert, aztán nézd meg, hogy mi jön vissza, hisz XML/JSON, látszik belőle! Abból meg majd megcsinálod magadnak az osztályokat! Hja, hogy service leíró az már nincs? Szopoládé.

Na elmehet mindenki valahova ezzel a fassággal...

( XMI | 2014. 07. 24., cs – 16:12 )

Ez valóban idegesítő. Az az érdekes, hogy pl egy java interface, jaxb annotációkkal egy meglehetősen egzakt(*) deklaratív leírást tud adni egy REST API-ról. Ennyi erővel lehetne adni egy programnyelvtől független leírási formát is.

(* disclaimer: olyan mélységig nem ástam bele magam, hogy minden corner-case-t leellenőrizzek, de elég kevés problémás eset van. Illetve egy terület van, amitől falra tudok mászni: a teljesen custom autentikációs megoldások. Sajnos Rest API-knál valamiért elég nagy divatja van, hogy mindenki feltalálja a saját autentikációs protokollját és ezeket sajnos nem lehet deklaratív API leírással lefedni.)
---
Régóta vágyok én, az androidok mezonkincsére már!

Tippre azért, mert most ezt nyomják mindenkinek, hogy RESTful jajdejó, meg jajhát ez sokkal kevésbé bloatabb, mint a SOAP, mert nem küld annyi XML elemet (könyörgöm, mintha a SOAP arról szólna, hogy te miben küldöd. Pont, hogy függetlenné lehetett volna tenni a adatok továbbítását, mehetne akár JSON-ban, binárisban, füstjelekkel, akármivel).

Mondjuk tegyük hozzá, sokan a SOAP-ot is borzasztó rosszul hasznáták, aztán jobb esetben XmlDocumentként, rosszabb esetben string-ként XML-eket küldözgettek...

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Amúgy ha már elméleti síkra terelődött, akkor a SOAP szerintem más miatt bloat. Gyakorlatilag egy sima socket felett is működhetne, annyira mindent maga akar megoldani és semmit nem használ ki a HTTP lehetőségi közül.

Ez nem csak egyszerűen csúnya, hanem technikailag is gáz, mert a HTTP cache-elésre és load balancingra kitalált megoldások gyakorlatilag semmit nem tudnak kezdeni vele.

Persze Rest-et is nagyon körültekintően kell használni, hogy egy http cache-sel jól működjön (cache-control, etag, if-modified-since, if-none-match, last-modified - mindet értelmesen implementálni kell), de legalább lehet.
---
Régóta vágyok én, az androidok mezonkincsére már!

Igen, a SOAP is felült a "tegyünk mindent HTTP-re, mert az trendi" szopórollerre, sajnos. Viszont akárhogy is nézzük, az egy RPC szolgáltatás, nem dokumentum-szolgáltatás, annak jó volt és használható volt. (Amúgy asszem erre a socketes dologra nyújt is valamit a WCF, de annyira nem ismerem a WCF-et.)

RESTful meg próbálja elővenni a HTTP-s részét, csak az a probléma, hogy megpróbálják API-nak eladni a SOAP helyett. Amit meg nagyon nem kellene.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Igen, mert ha rendesen implementálják, akkor lesz schemadefinicióm arról, hogy mit böfög vissza a szerver.

Vagy nem.

Szóval ott tartunk, hogy a RESTful nem váltja ki a SOAP-ot, de cserébe még szarul is implementálják sokan.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Egyébként az Amazon csinálta azt, hogy WSDL leírót adtak ki az AWS API-kra, amit egyrészt nyilván lehet SOAP felett "fogyasztani". Viszont egy szisztematikus leképzéssel ugyanebből a WSDL-ből csináltak REST API-t is. Tehát végülis valami kicsavart módon WSDL-t használnak REST sémadefiníciónak.

(Ebben az a vicces, hogy az Eucalyptus a saját API-ját az Amazon által kiadott ec2.wsdl-ből generálja, tehát elviekben 100% kompatibilis kéne legyen. Csakhogy elcseszték a WSDL->Rest leképzést a listák/tömbök környékén, emiatt sokminden teljesen máshogy működik. Triviális volna kijavítani, de mivel már számtalan 3rd party kliensprogramban bedrótozva ott az Eucalyptus-specifikus gányolás ezért nem nyúlnak hozzá.)
---
Régóta vágyok én, az androidok mezonkincsére már!

Na hármat találhatsz miért raknak mindent HTTP-re! Nem azért mert "trendy". Sokkal erősebb hajtóerő mögötte, hogy a HTTP átmegy a céges web proxykon. Ezen egészen addig röhögtem, amíg nagycéges környezetbe nem kerültem. Azóta inkább sírok.
---
Régóta vágyok én, az androidok mezonkincsére már!

Ezzel nem megyek semmire, mivel nem én biztosítom a service-t, hanem nekem kell használni. Ilyenkor azért ordas nagy gányfos megoldás az, hogy "há' nézd meg a kimenetét!".

Plusz, ameddig egy SOAP WebService esetén már kész API-t kaptam, addig ezzel még mindig csak ott tartom, hogy tudom, hogy mire számíthatok.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( siposa v | 2014. 07. 24., cs – 17:15 )

Részben egyetértek, de ha nincs az alkalmazott környezetben normális SOAP támogatás, akkor üdv a pokolban.

Így van, csak ha beterveztél rá 1 napot, hogy pikk-pakk beilleszted a távoli hívásokat a rendszerbe, és közben derül ki, hogy az úgynevezett támogatottság csak a "Hello world!" szintű problémák lefedésére elegendő, akkor cumi van: nyilván megoldja valahogy az ember, de megy a hajtépés.

Amúgy részemről Oracle Apex, PL/SQL volt a móka tárgya, ráadásul én javasoltam a SOAP-pot még a tervezési fázisban (szabványos! enterprise!!!), szóval házhoz mentem a l*f*szér :)

Most akkor kell XML vagy nem kell?
Pont te írtad le itt, hogy nem kell az XML a SOAPhoz:
http://hup.hu/node/134117?comments_per_page=9999#comment-1761529

Most meg azzal érvelsz, hogy kell.

Elárulom a nagy titkot: nem a SOAP a megváltás, és a nem a REST szar. A hiba abban van, ha nincs az interfész normálisan definiálva.
Az, hogy ez technikai szinten hogyan történik (WSDL leíró) vagy másképpen (pl. egy WADL + JSON-Schema) az édesmindegy.
Én például tökéletesen tudom használni a REST-et anélkül, hogy tudnék róla, hogy milyen lesz a kimeneti JSON vagy éppen mik az URL-ek.
JAX-RS + interface definíciók + DTO-k + proxy osztályok az interfészekre.

"Most akkor kell XML vagy nem kell?"

Kelleni kell, mert most azon keresztül megy. De elméletben lehetséges lenne akármi másra lecserélni a hordozó formátumot.

"Elárulom a nagy titkot: nem a SOAP a megváltás, és a nem a REST szar. A hiba abban van, ha nincs az interfész normálisan definiálva."

Oké, csak van különbség aközött, hogy egyik oldalon megmondom az osztályoknak, hogy TADA, a másik oldalon behúzom a WSDL-t, és szintén TADA és az egész SOAP-ból annyit látok, hogy itt bemegy egy ojjekt, túloldalt kijön egy ojjekt, aztán visszadobok valami ojjektet, ami szintén ojjektként köt ki az eredeti hívó oldalon. És az egész HTTP-ről meg az XML-es baszásról, ami a felszín alatt történik, nagy ívben szarok. Na most ennél a nyomi Web """API"""-nál ez nincs meg. És most erre recskáznak egyesek, hogy mekkora innováció. Hát nem.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Az eredeti SOAP API-nál sincs ez meg. Envelope-ok vannak meg XML hányások, amelyeket bizonyos frameworkök elrejtenek előled.
Használtál már gSOAP-ot SOAP-ra vagy valami kényelmesebbel dolgoztál? A gSOAP is szopás, hiába SOAP.

A REST is ugyanez: ha van egy jó framewörköd, akkor ojjekt meg ojjekt dolgozik össze, te nem is látod, hogy a háttérben HTTP van.

Szerencsére hozzám már csak akkor jutott el, mikor már ez működött.

"A REST is ugyanez: ha van egy jó framewörköd"

Értem, de ha kapok egy ilyen webhányást, hogy tessék ez van, meg ilyen XML kérések vannak, amire jön valami, akkor mit tudok tenni?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

ne tedd ezt velunk :'(

a SOAP meg mindig nem tartalmaz kikotest a transzport kozegre, igy tulajdonkeppen a papircetlin vagy a stdin/stdout-on kuldott SOAP uzenet is valid SOAP

ugyanez java-ban: https://metro.java.net/guide/ch09.html

tessek, nincs WCF, van viszont tcp, mint transzport.

Kulonbseg az, hogy egy tipusbiztos, schemadefinicioval rendelkezo hányás, amit egy szines-szagos dobozban adnak oda, amibe tudok dolgokat dobalgatni es hányás helyett ugyanugy jol definiált dolgok pottyannak ki. (persze, vannak fogyik, akik nem értették meg a dolgokkal való dobálózás lényeget, es szeretnek ugyanugy hanyast (public XmlDocument Csapassas(XmlDocument input) dobálni SOAP felett ide-oda, de azokat most hagyjuk.

A probléma az, hogy ennek csak a hányás van.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Az oke, csak most jelen esetben egy SOAP-os service helyett kell egy ilyen webapis izet hasznalnom, raadasul a fel webet azzal kurtolik tele, hogy de jo ez igy, mert RESTful meg babamfasza...

Innentol kezdve azert elegge osszehasonlithato.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™