RESTful, REST-like vagy SOAP API?

Programozás

RESTful
20% (61 szavazat)
REST-like
15% (46 szavazat)
SOAP
11% (33 szavazat)
Egyik sem, mindnél tudok jobbat
8% (23 szavazat)
Nem ismerem ezeket
46% (139 szavazat)
Összes szavazat: 302

( dejo v | 2015. 02. 14., szo – 11:59 )

A SOAP-ról már hallottam. A fürdőszobában a szappantartóra volt írva! :-)
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Ugy kell ezt elkepzelni, mint a HOVD-os "kedvenc ..." szavazasokat: melyik a legszimpatikusabb. Ettol meg lehet vele ugy az ember, hogy hol az egyik hol a masik hol pedig a harmadik a legjobb megoldas, de akkor is, valamelyiket jobban szereti hasznalni/irni.

( _Franko_ v | 2015. 02. 14., szo – 14:37 )

Mikor melyik... feladattól függ.

( inagy | 2015. 02. 14., szo – 15:40 )

Aki azt válaszolta hogy "mindnél tudok jobbat", leírná még is mik ezek? :)

Egyébként én a SOAP-ot kerülöm ha lehet. Szerintem borzasztóan nyakatekert formátum, ugyanilyen okokból kuporodom magzatpózba ha SAML-ös SSO-val kell foglalkoznom. Tény viszont hogy a RESTful dolgokra nem sok szabványos leíró formátum létezik, mármint a SOAP-ból lehet kliens és szerver vázat generálni de a REST-ből nem nagyon. Nálunk most a JAX-RS+Apache CXF vált be gépi oldalon és Swagger-el megsegítve készül hozzá humánusabban interaktív dokumentáció. De ennek is megvannak a limitjei.

Feladatok:

- old meg, hogy a tcp sockethez böngészővel is lehessen csatlakozni
- old meg, hogy a formátumodat több nyelvből is el lehessen érni (javascript, java, c++, etc.)
- old meg, hogy egyszerűen lehessen bővíteni

És máris ott tartasz, hogy valamilyen encoding protokoll-t használsz tcp felett (asn.1, google protocol buffers, thrift, fast buffers, messagepack, etc.) Ha meg bejön, hogy
böngészőből is el kell tudni érni, akkor jórészt a websocket marad.

Úgy értettem hogy ha teljesen egyedi protokollt kell fejleszteni akkor azért van értelme valami szabvány szerint leírni mintsem kézzel hegeszteni.És ugye bejön a kérdés hogy szerver szerver kommunikációra kell, vagy kliens szerverre, a kliens általában mi lesz, stb. Illetve hogy mennyire bonyolult üzenettipusok vannak. Ha mint az ftp smtpnél akkor persze elég lehet egy szöveges cucc de általában nem ez a helyzet.

Hehe, köszi a megosztást. Elég jól összefoglalja amikbe bele lehetne kötni :)

Én egyébként pont a SOAP stack inkompatibilitással szívtam egy fél éve. Az Axis féle SOAP stack bár protokoll verziószámban kompatibilis üzeneteket adott, még sem működött együtt endpoint definícióban a Spring-es JAX-WS provider-el. Kézzel kellett faragnunk a WSDL-t addig amíg a régi klienseknek is jó volt, és az új kliensek sem küldtek a szerver számára értelmezhetetlent. Pár hétre rá bejött hogy az egyik partner .NET-ből akarta ezeket hívni, és természetesen ez sem ment zökkenőmentesen.

Most ugyanezt játszom el Shibboleth és Spring Security SAML között :(

Érdekes, használtam már mindenféle kombinációban Javas, .NET-es és PHP-s soap servicet, inkompatibilitási probléma csak annyi volt, hogy a PHP-s cucc, ami a WSDL-t generálta, nem kezelt le valamit. De az talán nem a SOAP hibája, hogy egy SOAP lib fosul van megírva.

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

Ez az egyik. Másik, hogy miután neked egy API csonkod van, lehetőség meglenne arra is, hogy valami hatékonyabb transzport formátumra cseréljék az XML-t. (WCF-ben mintha lenne is ilyen, csak azt annyira nem ismerem).

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

( Gyuszk v | 2015. 02. 15., v – 17:30 )

Nincs kedvencem. A REST-et könnyen elcseszik azok akik nem értenek hozzá (i.e. a rest resourceok által képzett 'api' nem lesz egy cseppet se pragmatikus, hanem inkább kaotikus), a SOAP -ban viszont több a ceremónia (cserébe van épeszű contract a szerver és a kliensek között).

--
arch,debian,openelec,android

dev: http://goo.gl/7Us0GN
BCI news: http://goo.gl/fvFM9C

Nem tudom a REST-ben mit lehet elrontani (vagy en nem ertem igazan).

Nalam a REST igy csapodik le:

webszerverem/api/things -> megkapom az osszes cuccot
webszerverem/api/things/:thingid -> megkapom az adott :thingid-ju cuccot

Ezt tudom modositani (http post visszakuldom a teljes thing-et).
Tudom torolni (http delete)
Tudok ujat letrehozni (http put)

A webszerver meg lenyegeben annyit csinal, hogy ezeket lekepezi adatbazis hivasokra, vagy egy kis logikaval megspekeli.

Ezt hogyan lehet elrontani?

Baromi egyszeru debuggolni (bongeszobe epitett developer tools-szal), akar wget-tel lehet ellenorizni. Az auth layer-t tok egyszeru racsapni (jwt, cookie).
Tok egyszeru android-os klienst irni hozza (ott ugye cookie nem jatszik).

Debuggolast segiti, hogy szerver oldalon ha gondolod, az auth-ot kiveszed a hivasokbol...

Nem latom, hogy ennel hogyan lehet egyszerubbet csinalni.
Es azt sem, hogy ezt hogyan lehet elrontani.

Ertheto mi megy a halozaton, eleg egyszeru ahhoz, hogy nem kell segedprogram se, csak a ket szep szemed.

Bar a SOAP-hoz nem ertek olyan melyen, hogy erdemben le tudjam szolni...

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

| Nem tudom a REST-ben mit lehet elrontani (vagy en nem tudom igazan).

Általában azzal, hogy nem értik meg a REST mögötti koncepciót a fejlesztők, és csak RPC-ként tudják használni, pedig nagyon nem az.

A REST tényleg jó tud lenni - megfelelően használva. Egy RPC-megoldásról áttérni REST-re kicsit olyan, mint mondjuk először használni OOP nyelvet: könnyű abba a hibába esni, hogy OOP-nek (REST-nek) látszó dolgot csináljunk, ami valójában ugyanolyan imperatív kód (RPC-hívás) mint a váltás előtt.

Az SPDY-s szálban már valaki írt egy példát:

/api/users/...
kontra
/api/users/new/...

A második változat azért rossz, mert keveri a REST-et és az RPC-t. Működhet, de nem RESTful. A REST lényege, hogy resource-okban gondolkodik, míg az RPC függvényhívásokban.

Nagyon leegyszerűsítve, ha az URL-ben vannak igék, vagy "new" és hasonlók, akkor az jó eséllyel nem igazi RESTful API.

Aham, ertem.

A gyakorlatban, meg normalis framework ezt alapban tudja,
igy erolkodni kell, hogy ezt elrontsd (/new).

De engem kulonosebben nem kell meggyozni.
Nagy megelegedettseggel barkacsolok
REST+CRUD kereteben frameworkot hasznalva,
igy minden mukodik szepen mindket oldalon.

Ha majd valamibe belefutok,
ami a REST hianyossagaira vezetheto vissza:),
akkor atgondolom a velemenyem.

Addig kodolgatok nyugodtan es *gyorsan*.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Félreértesz, ez nem a REST hiányossága. Adott egy technológia, amit sokan hajlamosak rosszul használni. Ennyi a történet.

Ugyanez igaz rengeteg más dologra: a REST önmagában nem jó vagy rossz. Van olyan feladat, amire jó, és van olyan fejlesztő, aki tudja használni. Meg olyan is van, hogy a feladathoz/fejlesztőhöz nem passzol.

Én a SOAP-ot preferálom, annak ellenére, hogy a SOAP-ot is lehet sz*rul használni, pl. XML-t utaztatni sztringként. Ettől viszont nem a SOAP lesz rossz, hanem a fejlesztő.

"Adott egy technológia, amit sokan hajlamosak rosszul használni. Ennyi a történet."

Tévedés, annyi a történet, hogy adott egy buzzword arra, hogy használjuk a HTTP-t a szabványnak megfeleloen, csak epp a hyperek által leváltani készült technologiaknak nem helyettesítő terméke.

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

Szia,

milyen nyelven/frameworkkel dolgozol, adatbázist hogyan éred el? Csak azért kérdezem, mert most mi is RESTezünk, és kiváncsi lennék
mások hogyan fejlesztenek... ami engem az egész fw-ösdiben zavar, hogy nálunk a backend pl. atombuta, lényegében csak
json->tipizált object->adatbázis access-t csinál, és azon tűnődöm, hogy ezt a konverziót nem-e lehetne kivágni a francba, mert
ebben a formában haszna nincs, de legalább kódolnivalót ad.

node.js + yeoman template generator kodokra.
Plusz mongodb, couchdb es mongoose.

A mongoose-t lehet kivagom, csak tok kenyelmes, es az auth reteg abban van.

A template generator belekenyszerit egy kodstrukturaba, ami erre (webes alkalmazasok) van kihegyezve. Szerver oldalon lenyegeben api endpoint-okat enged, kliens oldalon meg angular-ral (de lehetne emberjs vagy barmi mas) epiti a html-es guit.

De tetszik, mert alapban van egy one-page app-od,
van szerver oldali adatbazis, websocket kezeles, miegyeb.

Az egeszet becsomagolod egy docker-ba, oszt' jonapot.

Persze security-hez nem ertek, meg a szokasos warningokat gondold hozza:)

json->tipizált object->adatbázis access-t csinál,

Ez annyival tud tobbet, hogy valami logikat betehetsz a json <-> adatbazis koze.
Tehat nem egy adatbaziselerest tolsz ki http-n,
mert akkor lehetne siman couchdb-t hasznalni angularbol,
mindenfele szerver nelkul.

Igazabol ez a MEAN stack, amit mindenki emleget meg trendy:)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Például azt hogy a HTTP metódusokat nem megfelelően használják, POST használata akkor amikor nem hozunk létre semmiféle új erőforrást, illetve a különféle resource-ok és resource részfák nem egységes nevezéktan alatt vannak, hanem összevissza... sok mindent lehetne írni.

--
arch,debian,openelec,android

dev: http://goo.gl/7Us0GN
BCI news: http://goo.gl/fvFM9C

"Nem tudom a REST-ben mit lehet elrontani "

Mindent. Kezdve azzal, hogy nem kapsz definíciót a dokumentumokról, amik jonnek-mennek, aztán mellékelnek neked valamit. Aztán a tényleges service meg vagy olyan, vagy nem. SOAP-nal ebből század annyi problémám volt.

Amugy REST=valaki elolvasta a HTTP specifikációt, es feltalálta a spanyol viaszt.

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

"Hol van az előírva, hogy a REST serviced csak jsont adhat vissza?"

Ezt most honnan vetted? Senki nem írt ilyet.

"Vajon jonak nevezhető az, amihez gyárilag workaround kell?"

Ez nem egy workaround, hanem egy tool, amivel könnyebben készíthető dokumentáció, meg generálható kód a kliensek számára.

Azt hiszem, kifejtettem mar sokszor, hogy - miután - tévedésből sokan RPC szerűen kezdik el használni és magára a dokumentumra sem tartalmaz kikotest (megis egybemossak sokan a JSON-nal), nem oldja meg a problémát, csupan ad egy maszatolast ra, új buzzwordokkal megtoldva, hogy a marketing ul tudja adni ugyanazt, ami mar egyszer mukodott.

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

( zoli78 | 2015. 03. 03., k – 16:58 )

Szerintem igazából ez a céltól függ.