- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Ez érdekes. Tudtommal az SPDY-t pont ők és pont erre fejlesztették. Nem világos, de nekem az jön le a bejelentésből hogy ezt is ők tervezték meg?
- A hozzászóláshoz be kell jelentkezni
A HTTP/2 az IETF-nél készült, de a szabvány kiindulópontnak vette a SPDY-t, ugyanakkor tovább is lépett rajta néhány ponton. A bejelentés is azt mondja, hogy örülnek, hogy olyat tettek le az asztalra, ami az új szabványhoz vezetett.
______________
ArchLinux user
"If you immediately know the candlelight is fire, the meal was cooked a long time ago."
- A hozzászóláshoz be kell jelentkezni
Részben, de ők is az "author"-ok között vannak [ https://tools.ietf.org/html/draft-ietf-httpbis-http2-16 ], talán még pár szabadalmat is "szabaddá" tettek a googliék a HTTP/2.0 szabványhoz...
- A hozzászóláshoz be kell jelentkezni
Szerintem lassan mindenki jobban járna egy szabványos, jól átgondolt rpc megoldással, az egyes protokollok pedig csak fuggvenyhivasok, és azok paraméterei, visszatérési értékei lennének...
--
zsebHUP-ot használok!
- A hozzászóláshoz be kell jelentkezni
Van, nem is egy. Olyan is van, ami HTTP felett megy. Csak mivel webről van szó...
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Vegulis a vilag osszes alkalmazasa mukodhetne pl. SOAP-al, vagy JSON-RPC-vel, vagy XML-RPC-vel, HTTP felett, de nem biztos hogy ezt akarjuk :)
--
arch,debian,openelec,android
dev: http://goo.gl/7Us0GN
BCI news: http://goo.gl/fvFM9C
- A hozzászóláshoz be kell jelentkezni
A Corba kimaradt... jó pár éve még corba alapon kommunikált a szoftverünk, az első lépésünk az volt, hogy az egészet kib@sztuk és lecseréltük egy szabványos TCP/IP socket
alapú megoldásra. Azóta nincs is vele semmi gond. Mostanában meg REST + JSON alapú interface-eket irogatunk, és teljesen jól és logikusan lehet vele fejleszteni, nem
igazán szeretnék újra SOAP/xxxRPC-t látni...
- A hozzászóláshoz be kell jelentkezni
Inkább pont az ellenkezője. Lassan mindenki jobban járna, ha a jól átgondolt rpc (szinkronizált és ezért blokkoló) megoldások helyett még jobban átgondolt aszinkron (ezért nem blokkoló) megoldásokat használna.
- A hozzászóláshoz be kell jelentkezni
Nyilván, ez az alap.
--
zsebHUP-ot használok!
- A hozzászóláshoz be kell jelentkezni
Azért arra érdemes lehet figyelni, hogy embedded világban is előfordul a HTTP. Nem árt, ha egy ilyen megoldásnak lenne faék egyszerűségű megvalósítása is...
- A hozzászóláshoz be kell jelentkezni
Sok esetben nincs rá szükség. Pontosabban, mindkettőre szükség van, mindkét irányba. Viszont ezekre a HTTP alkalmatlan.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Akkor ezt mi teljesen máshogy látjuk.
- A hozzászóláshoz be kell jelentkezni
A HTTP egy dologra alkalmas: URL-ekkel azonosított entitásokon előre definiált műveletek (GET, HEAD stb.) végrehajtására. Aki ezen felül használja (sokan) azok csak transzport protokollként használják egy RPC mechanizmus felett. Használhatnának direkt TCP/IP-t is, SOAP-over-HTTP-t is stb.
- A hozzászóláshoz be kell jelentkezni
Igen, pontosan :D ellenben ez most valamelyest változik a HTTP/2-vel...
HTTP-alapú (pl. REST) megoldás kifejetezzen a "stateless" megoldásokra hajaz, szóval konkurens kérés kezelés vagy "feliratkozás" eseményre ki volt lőve.
HTTP/2 ellenben egy kiskaput nyitott: 1 tcp streamet kezel / cliens így a cookie/auth viszonylag felesleges (SSO/stream, session data lehet streamhez kötve), és multiplexinggel felügyelni/átrendezni lehet a választ is (multipart/trailing header). Azaz a HTTP/2 gyalorlatilag "stateful"...
Arról nem is beszélve hogy a websocket (mint framed bidi stream) natívan beleépül, így egy minimális headerrel (2-10 byte WS header + 16? byte HTTP/2 header) rendelkező websocket framebe olyan protocolt ágyazhatsz, amit csak akarsz (több socketet is nyithatsz/cliens).
Jó példa erre az autobahn vagy WAMP (protocol), azaz rpc+subscription alapú protocolok egyszerre, vagy az eventstream amit manapság minden böngésző támogat (ez csak unidir, de a pollingot leváltja). HTTP/2-vel ezek a megoldások akár natív (xhr és server-push) szinten is alkalmazhatóak.
Persze megvan az ára: a jó öreg kérés-válasz alapú rendszerek valszeg majd ritkulnak, és sokkal inkább event-loop alapú programok/nyelvek/httpd-k fogják átvenni a vezetést, ezzel is még jobban minimalizálva a latency-t és közelebb tolva a "web"-et a "realtime" rendszerekhez. Nem realtime kernelle gondolok, hanem arra hogy a szerver-kliens kommunikáció 3-5 nagyságrenddel lehet gyorsabb... pillanatnyilag asszem "C1M" a rekord SPDY-vel, mint 1 millió konkurens kliens / átlag VPS (a gigabit sávszél korlátozza ennyire). lásd "C10K problem".
- A hozzászóláshoz be kell jelentkezni
Tehát építettünk a TCP fölé még egy réteget, ami ugyanazt tudja, mint a TCP. Főleg ha a custom protokollokra gondolok...Csodás.
- A hozzászóláshoz be kell jelentkezni
Igen, mondjuk ezen gondolkodtam, hogy ne már az legyen a feature hogy a TCPIP felé rakunk egy réteget, ami lényegében pont azt tudja majd, amit a TCP/IP adott :) ráadásul van websocket és az teljesen jól működik ...
- A hozzászóláshoz be kell jelentkezni
> Tehát építettünk a TCP fölé még egy réteget, ami ugyanazt tudja, mint a TCP.
Igen, ugyanazt mint a TCP (kis túlzással, mert a packetek mérete 3-5%-kal csökkent), és még bonuszként HTTP és sok kapcsolódó kiegészítő szabvány is egyben.
> Főleg ha a custom protokollokra gondolok...Csodás.
A SPDY és így a HTTP/2 alapelve, hogy a tcp réteget nem szabad basztatni, inkább "transparent extend" legyen, ami széles körben használható standard.
Pont az egyedi TCP alapú megoldásokat akarja központosítani/stadnardizálni/egyszerűsíteni.
A HTTP/1.1 ha úgy veszed 2 réteg a TCP felett:
TCP stateful -> TCP packet stateless -> HTTP összegyűjti a stateless packeteket statefull módon egy request-té -> HTTP request az stateless -> opció: ha kell, cookie/session handling, hogy script/app oldalon visszaalakítsd stateful-á.
+ gyakorlatilag ugyanez HTTP response-ra visszafele (a kliens oldalon natív/nincs session handling).
- A hozzászóláshoz be kell jelentkezni
Annyi kulonbseg van, hogy a HTTP-nek van hozzaadott erteke, a headerek, a methodok, cache control, mindennek van jelentese. Viszont ha implementalhatsz custom byte-level protokollt HTTP-n ugy, hogy az eredeti HTTP szemantika elveszik, es tkp egy socket kapcsolatod van, akkor az egesznek nincs ertelme.
A HTTP pedig nem veletlenul stateless: amire valo, az stateless modon mukodik, nem letezik az a fogalom, hogy session, legalabbis a protokoll szintjen nem is kell leteznie. Entitasokat azonositasz URL-ekkel, es ezen URL-eken vegezhetsz par muveletet.
Az meg, hogy webre stateful dolgok kellenek, mar nagyon regota tudott. A HTTP-t meg kifacsarjak, hogy legyen benne allapotkezeles, meg hogy legyen benne full-duplex ketiranyu kommunikacio a half-duplex request/response helyett.
Csakhogy erre mar regota ott a TCP es a custom protokollok.
Sokkal egyszerubb lenne, ha JS-ben nyithatnal barmilyen socketet, barmilyen protokollon byte-szeruen elerve, es voila, megoldodik minden. Pontosan ugy, ahogy a Java Appletek es a Flash ezt mar regota tudta.
- A hozzászóláshoz be kell jelentkezni
Alternatívaként azért a websocket ezt a problémát megoldja, illetve azt is garantálja, hogy ha elküldesz valamit, akkor a másik oldalon az egyben fog megjönni, nem kell
a packet összerakással bohóckodni...
- A hozzászóláshoz be kell jelentkezni
Rendben. Akkor írj egy olyan javascriptet, ami majd natívan kapcsol neked TCP streamet HTTP/websocket nélkül, és minden ~mai (IE?) stock böngészőben/platformon (HTTP/2 támogatott rendszeren vagy embeded környezetben) megy.
Ha nem sikerül megoldani, akkor marad a stream HTTP alatt, függetlenül attól, hogy milyen protokolt használsz a TCP streamen.
HTTP sematika elveszik, ha a websocketet TCP-ként használod, ez tény.
De megmarad, ha XHR-t küldesz vagy server-push-t kapsz. Ellenben az XHR és a server-push része a HTTP-nek, így közvetlenül használható event-loopban server és cliens oldalon. Tehát a WAMP/autobahn-hoz hasonló protokolt össze tudsz legózni percek alatt (websocket nélkül is), plusz overhead nélkül és minden HTTP/2 rendszeren ~közel TCP sebességgel megy.
- A hozzászóláshoz be kell jelentkezni
" Akkor írj egy olyan javascriptet, ami majd natívan kapcsol neked TCP streamet HTTP/websocket nélkül,"
Irnek en, ha a JS API megengedne bongesziben. NodeJS alatt megoldott a dolog. Nem nyelv, hanem runtime-specifikus a dolog. Az, hogy a bongeszokben nincs implementalva, az egy dolog.
"HTTP sematika elveszik, ha a websocketet TCP-ként használod, ez tény.
De megmarad, ha XHR-t küldesz vagy server-push-t kapsz."
Pont te emelted ki, hogy milyen jo dolog mar, hogy HTTP/2-ben lehet sajat protokollt implementalni WebSocket felett.
Oda jutunk, hogy a HTTP/2-vel eljutunk oda, hogy elvesztjuk a HTTP valodi funkcionalitasat, mert mindenki sajat protokollt fog epiteni WebSocket felett. Egy ido utan pedig eljutunk oda, hogy bongeszoben is lesz TCP socket kezeles JS-bol. Persze minden csak ido kerdese.
Mar itt beszelgettunk par eve arrol, hogy mikent is alakul a HTTP ( http://hup.hu/cikkek/20110806/20_eves_a_web?comments_per_page=9999#comm… ) es egy kis osszehasonlitas a TCP-vel. Evek kerdese, es a HTTP egy nagyon kis reteg lesz, nagyon feleslegesen a TCP felett. Mert rajonnek majd, hogy a TCP jo :)
Es majd JS-ben lesz library (vagy platform support, lenyegtelen) TCP feletti dokumentumlekerdezesre HTTP/1.1 modon (mint most az XHR), meg minden mas library minden mas protokollra (SMTP stb).
Es ilyenkor jut eszemeb az embernek Jamie Zawinsky torvenye, csak eppen protokollokra bontva:
"Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can."
A HTML X-edik verzioja HTTP Y verzioja felett el fog jutni oda, hogy nativan kezelnek SMTP kapcsolatot majd a scriptek. Ido kerdese csak. Nem lenne egyszerubb megsporolni ezt a par evet?
Persze tudom, el kell adni csomo tanfolyamot, csomo konyvet a HTTP 2.4-rol is meg a WebSocket 5.6-rol, meg a HTML6-rol is.
- A hozzászóláshoz be kell jelentkezni
Figy, már http 1 alatt is megy a websocket, nem kell ahhoz http 2. És igen, mi is implementáltunk saját, asn.1 alapú protokollt websocket felett. Miért? Mert volt egy szerverünk, ami standard tcp/ip socket kapcsolatot tudott, és volt egy desktop alkalmazásunk, ami pedig ehhez csatlakozott. Most csak annyit kellett változtatni, hogy a szerver websocket kapcsolatot is tudjon fogadni (kb. két nap fejlesztési idő volt) és a klienset pedig újraírhattuk webre, így sima böngészőből is elérhetik a felhasználók, és nem kell semmit sem telepíteni a gépekre. Nálunk a cél az, hogy egy platformra tudjunk fejleszteni, lehetőleg egy nyelven, ezt pedig a webböngésző biztosítja.
- A hozzászóláshoz be kell jelentkezni
A webböngásző? Melyik? Van olyan, amelyik nem támogat WebSocketet. A web is egy törékeny platform, főleg ha még mobil támogatás is kell.
- A hozzászóláshoz be kell jelentkezni
http://caniuse.com/#feat=websockets
Mivel a mi termékünket belsős rendszerben használják, fix gépeken, ezért még azt is kiköthetem, hogy firefox 38 kell :) Hiába, no, kényelmes az életünk. De gyakorlatilag minden modern böngésző támogatja, még az IE 10 is. Ha pedig mobilra fejleszt az ember, akkor jó eséllyel saját alkalmazást ír, ahhoz meg van websocket könyvtár. De nekünk ez nem gond,
mert mobilt nem támogatunk.
- A hozzászóláshoz be kell jelentkezni
Ismerek olyan belső rendszert, ami fejlesztés alatt áll jelenleg is, és IE 8-on KELL működnie. Oldd meg WebSockettel, légyszíves.
- A hozzászóláshoz be kell jelentkezni
Ez most egy komoly hozzászólás volt? De tényleg? Leírtam, hogy vannak esetek - mint pl. a miénk, - ahol a fejlesztőnek lehetősége van meghatározni, hogy mit támogat. Szerencsére IE 7-8 stb. már a Microsoft által sem támogatott, tehát publikus oldalon is nagyjából leszarja az ember, hogy valaki ilyen retekkel böngészik. Az intranet az olyan szempontból más, hogy igen, vannak cégek, ahol ilyen igények vannak. Ilyenkor jönnek az olyan gányolások, mint java applet, flash plugin, activex komponens, és a többi. De ez nem jelenti azt, hogy ezek a megoldások technikailag jók, ezek szükségmegoldások.
https://github.com/gimite/web-socket-js
http://www.jwebsocket.org
A legtöbb esetben egyébként sincs szükség websocket-re, mert egyszerűen nincs szükség kétirányú kommunikációra, egy sima http request-response-zal mindent meg lehet oldani. Nekünk egy egészen speciális esetünk van, a websocket viszont lehetőséget adott arra, hogy a termékünket tovább tudjuk fejleszteni, "webesíteni".
- A hozzászóláshoz be kell jelentkezni
Mert a HTTP/2-t minden támogatja már?
Probléma az, hogy nem a HTTP-t kellene tovább erőszakolni, hanem kidolgozni egy olyan protokolt, ami képes RPC-re (ezzel kiváltva a HTTP kéréseket is) és aszinkron adattovábbításra mindkét irányba.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
>A HTTP pedig nem veletlenul stateless: amire valo, az stateless modon mukodik, nem letezik az a fogalom, hogy session, legalabbis a protokoll szintjen nem is kell leteznie. Entitasokat azonositasz URL-ekkel, es ezen URL-eken vegezhetsz par muveletet.
Most REST-ről vagy HTTP-ről beszélünk? Jó, hogy közel áll a kettő egymáshoz, de más a céljuk.
Igen a REST az kifejezetten arra épül hogy URI-val egyértelműen azonosítható dolgokat manipulálj, ahogy a HTTP is ezért készült a 70-es(?) években.
Ellenben a HTTP azóta jóval kinőtte az eredeti terveket (ezért lett külön fogalom a REST), és így már sokkal inkább a kommunikáció módjáról szól (pipelineing, upgrade, az egész webdav etc...) mint magáról az adatokról.
> Sokkal egyszerubb lenne, ha JS-ben nyithatnal barmilyen socketet, barmilyen protokollon byte-szeruen elerve, es voila, megoldodik minden. Pontosan ugy, ahogy a Java Appletek es a Flash ezt mar regota tudta.
Még sokkal egyszerűbb lenne, ha root jogot kapnál minden számítógépen ami meglátogatja a weboldalad.
Ezért van folyton secturity update flashre meg java-ra, de valahogy a javascript sose basztat hogy frissíteni kellene. (Max a browser, de az nem a JS vagy a HTTP hibája.)
- A hozzászóláshoz be kell jelentkezni
A REST maga a HTTP.
Nezd meg a HTTP specifikaciojat.
http://tools.ietf.org/html/rfc7230#section-2
http://tools.ietf.org/html/rfc7231
"The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems."
Erre valo a HTTP. Kesz.
HTTP-ben URI-val azonositott entitasok vannak:
"HTTP relies upon the Uniform Resource Identifier (URI) standard [RFC3986] to indicate the target resource (Section 5.1) and relationships between resources."
Ez az RFC 2014-es, a legfrisebb HTTP specifikacio.
Az egy dolog, hogy nem erre hasznaljak.
- A hozzászóláshoz be kell jelentkezni
Ha tudsz használni protocol upgraded REST-tel, akkor a tényleg REST === HTTP.
Mellesleg eredetileg kiskapuról ill. új lehetőségekről beszéltem a HTTP/2-ben, vagy nem?
De mielőtt nagyon flame-mé fajulna:
Igen, igazad van. A HTTP egy "application level" protokol nem ér fel a OS-natív TCP-vel. A HTTP semmi másra nem jó, csak egy elég behatárolt utasításcsoport paraméterekkel való meghívására, pont mint pl. az x86 utasításkészlet a procikban.
Én tévedtem, hogy azt hittem ilyesmit "bármi másra" lehet használni.
Pont ugyanúgy, ahogy pl. egy procit az x86 kezelésére találtak ki, másra nem való, és csak "vájtfülű hackelés" a hozzáadott utasításkészletek használata, neadjisten amd64 utasítások hívása...
- A hozzászóláshoz be kell jelentkezni
Kicsit máshogy. A HTTP ad lehetőségeket. A REST azt mondja, hogy ezeket a lehetőségeket hogyan érdemes használni, hogy egy "jó" web szolgáltatást adjunk.
"Representational State Transfer (REST) is a software architecture style consisting of guidelines and best practices for creating scalable web services."
- A hozzászóláshoz be kell jelentkezni
"Ezért van folyton secturity update flashre meg java-ra, de valahogy a javascript sose basztat hogy frissíteni kellene. (Max a browser, de az nem a JS vagy a HTTP hibája.)"
Mert a javascript runtime-ot úgy hívják, hogy webböngésző (illetve az engine-eket el szokták nevezni, de ez most lényegtelen mert az a böngésző része). Az meg nálam gyanúsan sokszor frissül. Pl. ez a hiba szerinted független a javascripttől?
- A hozzászóláshoz be kell jelentkezni
Na ezaz. A browser frissül 6 hetente security updatekkel, de ha a Java vagy a Flash évente kétszer frissülni mer, az már bizony undorító dolog! :)
- A hozzászóláshoz be kell jelentkezni
"Tehát építettünk a TCP fölé még egy réteget, ami ugyanazt tudja, mint a TCP. Főleg ha a custom protokollokra gondolok...Csodás."
Nem: csinaltunk a TCP folotti HTTP melle egy reteget, ami azt tudja mint a TCP, de atmegy a proxy-kon, meg 10 ev mulva is at fog menni a 20 eves ipv4 only routereken subnet alatti subneten, igaz mindezt igen korlatozott portvalasztekon tudja, de legalabb megse olyan lesz mint egy upnps portnyitas. Ja meg amihez HTTPS-nel mar bevalt modon konnyen titkositast dolgozhatunk ki egysegesen, szabvanyosan. Mindemelle a legtobbet hasznalt es ezert leginkabb tesztelt eszkozok fogjak ezt kezelni napi szinten: a bongeszok. Nem ertem mit ertetlenkedsz, eleg egyertelmu mi a szerepe
- A hozzászóláshoz be kell jelentkezni
+1
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni
Navégre! :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
- A hozzászóláshoz be kell jelentkezni
Szánalmas.
- A hozzászóláshoz be kell jelentkezni
Firefox 34
about:config
default beállítás ebben a verzióban:
network.http.spdy.enabled;true
network.http.spdy.enabled.v3;true
network.http.spdy.enabled.v3-1;true
nginx: listen 443 ssl spdy;
Jó kísérletezgetést!
- A hozzászóláshoz be kell jelentkezni
A SOAP szopas.
Webservice (REST-JSON) kiraly.
- A hozzászóláshoz be kell jelentkezni
Ne haragudj meg, de te nem ismered a válasz gombot, vagy direkt nem használod?
--
blogom
- A hozzászóláshoz be kell jelentkezni
ismerem; aszt (sz-szel) nyomtam, de ez a kocsog portalrendszer bejelentkeztetest kov etoen ide dobta a valaszt.
- A hozzászóláshoz be kell jelentkezni
Még jó, hogy másra valók. Az egyik távoli eljáráshívás, a másik meg egy URI/URL-alapú entitáselérési elv.
Ha meg te REST-JSON alatt olyan HTTP feletti távoli eljáráshívást értesz, ahol az eljáráshívás paraméterei és outputja JSON-ba van szerializálva, akkor nem tudod, mi a REST valójában.
- A hozzászóláshoz be kell jelentkezni
+1
A maguk nemében a különböző SOAP implementációk még mindig a legjobb választást jelentik. Bár tudom, sosem volt ennyire divat mindent szögnek nézni, mint mostanában a RESTful API-k kapcsán. :)
- A hozzászóláshoz be kell jelentkezni
-1
Kis rendszereknél, amit kevesen használnak és a teljesítmény valamint a rugalmasság nem számít ott még elmegy a SOAP.
Ajánlom figyelmedbe a Reactive Manifesto-t.
Van egy nagyon jó videó a témában, ami alapvetően a Play frameworkről szól, de itt van egy 7 perces rész belőle, ahol általánosan elmondja Yevgeniy (Jim) Brikman, hogy miért is nem jó a blokkolt kommunikáció.
- A hozzászóláshoz be kell jelentkezni
A SOAP miért ne lehetne nem blokkolóan megvalósítva? Főleg ha HTTP felett megy. Nem értelek.
Van két partner, aki beszélget SOAP-on keresztül HTTP felett. Az egyik a szerver, a másik a kliens (hiszen a HTTP így működik).
Namármost, miért is nem lehet SOAP-ot használni olyan HTTP szerver felett, ami aszinkron dolgozza fel a kéréseket?
Kifelé a kliens felé teljesen mindegy, hogy a szerver belül hogyan működik, a külső viselkedés szempontjából mindkét szerver megvalósítás ekvivalens kell legyen.
Mesélj még, mi a különbség aközött, hogy egy SOAP üzenetet küldök el, vagy egy REST metódust hajtok végre egy HTTP URL-en? A kliens szempontjából technológiailag (a HTTP-t tekintve) SEMMI különbség nincs. Szemantikai különbség van abban, hogy mit tartalmaz az adat, mit jelentenek az endpointok, mennyire használjuk a HTTP által nyújtott szolgáltatásokat (HTTP methodok stb).
Az, hogy szervereket event-driven módon szerint illik implementálni, annak semmi köze ahhoz, hogy a SOAP milyen. És ez igaz egy IRC szerverre is, nem csak HTTP szerverekre. Divatos dolog felülni a Play Framework és hasonló "I am the ultimate in performance" bandwagonra, csak tudni kell, hogy valójában mit csinálsz, nem pedig buzzwordöket egymás után tenni.
- A hozzászóláshoz be kell jelentkezni
Ugyanarra való mind a kettő, csak más koncepcióra épülnek.
Abban igazad van, hogy sokan rosszul használják a REST-et ("eljáráshívás paraméterei és outputja JSON-ba van szerializálva").
- A hozzászóláshoz be kell jelentkezni
Nem ugyanarra valók. A REST esetén te entitásokat küldesz ideoda, amely entitások egyértelműen azonosíthatóak URL-lel.
Az adott URL-re tett GET HTTP method magát az entitás egy reprezentációját kell visszaadja.
Míg SOAP esetén egy URL egy-egy eljárás címét jelenti, amelyhez küldhetsz bemenő paramétereket és ő majd kimenő paramétereket csinál belőle.
Elvileg a SOAP eljárásoakt is el lehetne érni REST módon (ekkor mnodjuk a reprezentációja az eljárás forráskódja lehetne).
- A hozzászóláshoz be kell jelentkezni
Ugyanarra valók, csak más a koncepció. Mind a kettő web service-re való.
Ugyanazt el lehet érni mind a kettővel, csak másként.
- A hozzászóláshoz be kell jelentkezni
Nem ugyanarra valók és a REST nem web service amúgy.
A web service mint fogalom valamiféleképpen jól definiált.
http://www.w3.org/TR/ws-gloss/#webservice
"It has an interface described in a machine-processable format (specifically WSDL)."
A SOAP például Web service, a REST nem, mivel a REST interface-t nem WSDL írja le.
- A hozzászóláshoz be kell jelentkezni
Ez egy szép web service meghatározás, de már kicsit túlhaladott :)
- A hozzászóláshoz be kell jelentkezni
El kéne dönteni végre, hogy mérnökök vagyunk, ahol minden szónak normálisan jelentése van, definiálva, vagy marketinghuszárok, akik hobbikóderek is egyben. Én inkább lennék az előbbi.
- A hozzászóláshoz be kell jelentkezni
http://docs.oracle.com/javaee/6/tutorial/doc/gijqy.html
Tessék, oracle is, ms is, minden cég web service-nek nevezi a REST-et. Alapvetően logikus is, hiszen egy szolgáltatást ad weben keresztül.
- A hozzászóláshoz be kell jelentkezni
A REST egy architekturális stílus, nem szolgáltatást ad, hanem entitásokat érhetsz el vele (resource a REST nevezéktanában) megadott URL-en és megadott metódusokkal.
És vannak olyan webszolgáltatások, amik RESTful-ok, azaz REST stílusban vannak megvalósítva. Ilyenkor magát a webszolgáltatást alakítod ki REST stílusban. A REST önmagában még nem egy webszolgáltatás, nem protokoll. Csak egy stílus (mint a procedurális vs OOP programozás).
Sokan félreértik a REST-et sajnos, és ugyanúgy RPC hívásokat működtetnek RESTful service-k létrehozására (tipikus példa mondjuk egy /filter?query URL-en elérhető resource és társai).
Itt a HUP-on és még sok más fórumon is sokszor vita szokott lenni azon, hogy amikor egy meglévő szolgátlatást REST stílusban akarunk megvalósítani, akkor mik legyenek az egyes URL-ek, hogyan valósítsunk meg régebbi nem RESTful működést.
Egy jó vita itt: http://hup.hu/szavazasok/20140223/restful_api-n_egy_get_hivasnak_lehet-….
A REST önmagában nem webszolgáltatás, csak egy stílus. Ezért nem szoktam érteni, amikor emberek azon örvendenek, hogy ők REST-et használnak és nem SOAP-ot. És? Ez nem előny vagy hátrány, hanem egy stílus.
Főleg az a szép, amikor azt mondják, REST-et használnak, és kiderül, mégsem, hanem egy saját JSON-nal működő RPC mechanizmust, amit ők REST-nek neveznek, mert nem SOAP :)
- A hozzászóláshoz be kell jelentkezni
"És vannak olyan webszolgáltatások, amik RESTful-ok, azaz REST stílusban vannak megvalósítva."
Nagyon kíváncsi vagyok, hogy ezen webszolgáltatásokat (web service-eket) mégis Te hogyan nevezed? (A világ ezeket RESTful web service-eknek vagy röviden REST web service-eknek nevezi. Google, MS, IBM, ...)
Illetve arra is kíváncsi vagyok, hogy ezek hogyan lehetnek webszolgáltatások egyáltalán, amikor nem is olyan rég mutattál rá, mint mérnök, hogy mi is pontosan a web service definíciója. Avagy a RESTful web szolgáltatásokat is "WSDL írja le"?
"Csak egy stílus (mint a procedurális vs OOP programozás)."
Pontosan! Röviden a SOAP az procedurális stílusú web szolgáltatás, a REST az OOP stílusú web szolgáltatás.
Nyelvtanilag nézve (ahol A=Alany, Á=Állítmány, T=Tárgy):
SOAP: ÁAT (vagy angolosan: VSO)
REST: AÁT (SVO)
- A hozzászóláshoz be kell jelentkezni
"A világ ezeket RESTful web service-eknek vagy röviden REST web service-eknek nevezi. Google, MS, IBM, ..."
Attól, hogy valami marketingbullshit, még nem kéne elterjednie. Persze mivel az egész web, úgy ahogy van, nem egy szabványos valami, ezért mindenki felül egy $RANDOM valaki által kitalált bandwagonra, mert éppen az a király.
Mivel nincs igazán definiált jelentése annak, hogy ami, hogy "RESTful web service" (láttál te már ilyet?), ezért mind a 3 felsorolt cég totál mást is érthet alatta. Láttam én már olyan RESTfulnak nevezett API-t a 3 fenti cég egyikétől, ami baromira nem volt valójában RESTful.
Például: https://developers.google.com/custom-search/json-api/v1/using_rest
"REST, or Representational State Transfer, in the JSON/Atom Custom Search API is somewhat different from traditional REST. Instead of providing access to resources, the API provides access to a service. "
Ez innentől kezdve nem RESTful és be is ismerik, csak éppen ezt a szót használják egy JSON-os RPC-re. Mintha valaki azt mondaná a JavaScriptre, hogy OOP. Nem az.
"Avagy a RESTful web szolgáltatásokat is "WSDL írja le"?"
A RESTful interfészeknek nincs gépileg teljesen értelmezhető és pontos leírónyelve és nem is lesz, mivel a REST egy stílus és nem egy szabvány. Ha lenne bármilyen géppel értelmezhető leíró, akkor mondjuk a Google, akinek rengeteg HTTP-n elérhető, félig-meddig RESTful API-ja van, miért nem publikálja ezt, miért dokumentációt kell böngészned és miért adnak inkább neked hivatalos klienst n nyelvhez?
- A hozzászóláshoz be kell jelentkezni
Attól, hogy valami nem szabványos, attól még egy létező dolog.
A W3C szerint is van REST compliant web service, bár ez azért nem teljesen ugyanaz, mint amiről a világ beszél (ez egy részhalmaza). Megköveteli az XML-t, kell WSDL, ...
"Mivel nincs igazán definiált jelentése annak, hogy ami, hogy "RESTful web service" (láttál te már ilyet?)"
Itt van a precíz leírása.
Van rá ajánlás, hogy és miként kellene csinálni, de mivel nincs rá szabvány (a fenti igazából az, de nem hivatalos szabvány), ezért nagyon sokan eltérően használják, és ez nem feltétlenül rossz. Vannak fokozatai, hogy egy megvalósítás mennyire követi az ajánlást. Olyan, mint a webböngészőknél a szabvány követése, egyik sem tudja 100%-ra, attól még azt mondjuk rájuk, hogy webböngészők.
"A RESTful interfészeknek nincs gépileg teljesen értelmezhető és pontos leírónyelve és nem is lesz".
Ha az ajánlások szerint van megcsinálva egy RESTful web service, akkor ugyanolyan jól le tud írni mindent, mint a WSDL.
Csak a kiinduló URL cím kell, onnan lekérdezhető az adott erőforrás, illetve, hogy azon az erőforráson milyen műveletek érhetők el, és az erőforráshoz milyen más erőforrások kapcsolódnak. Minden erőforrásnak van típusa (mime type), ha a kliens ismeri az adott típust, akkor tud is vele dolgozni.
"Mintha valaki azt mondaná a JavaScriptre, hogy OOP. Nem az."
Miért is nem? :)
- A hozzászóláshoz be kell jelentkezni
Fielding disszertációját ismerem, ő sem ad definíciót arra, mi a RESTful web service, csak leírja, hogy mi az a REST mint architektúra, és mint stílus.
Ez a mondat akkora bullshithalmozás, hogy hihetetlen. IT sales prezentációkban látni ilyet, nem doktori disszertációkban.
"REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems. "
"Olyan, mint a webböngészőknél a szabvány követése, egyik sem tudja 100%-ra, attól még azt mondjuk rájuk, hogy webböngészők."
Csakhogy meg tudod mondani, hogy mely W3C ajánlás az, amivel kompatibilisek teljesen. Viszont mivel a REST egy stílus, nem igazán tudod megmondani, hogy egy service valóban RESTful, vagy csak RESTful-szerű.
"Ha az ajánlások szerint van megcsinálva egy RESTful web service, akkor ugyanolyan jól le tud írni mindent, mint a WSDL."
Adj nekem egy leírást, amit megetetek egy IDE-vel vagy egy tool-lal és utána lesz nekem szép proxy osztályom, anélkül, hogy kézzel írnám. Ezt értem géppel értelmezhető leírás alatt. Mert a WSDL géppel feldolgozható.
"Csak a kiinduló URL cím kell, onnan lekérdezhető az adott erőforrás, illetve, hogy azon az erőforráson milyen műveletek érhetők el, és az erőforráshoz milyen más erőforrások kapcsolódnak. Minden erőforrásnak van típusa (mime type), ha a kliens ismeri az adott típust, akkor tud is vele dolgozni."
Ez így nem igaz. Ha én ismerem az application/json mime típust, fel tudom dolgozni BÁRMELYIK JSON-ben reprezenált entitást szemantikusan helyesen? Nem.
Ugyanígy: "illetve, hogy azon az erőforráson milyen műveletek érhetők el"
Ez REST-ben nem érhető el precízen. Nem, még OPTIONS-sel sem. https://www.mnot.net/blog/2012/10/29/NO_OPTIONS
JS-ben sok olyan dolgot nem tudsz megcsinálni, amit OOP-ben igen. Az encapsulation, polymorhism, inheritance hármasból egyszerre nem tudja a kettőt. A prototype-based inheritance kizárja a rendes encapsulationt.
- A hozzászóláshoz be kell jelentkezni
"Az encapsulation, polymorhism, inheritance hármasból egyszerre nem tudja a kettőt. A prototype-based inheritance kizárja a rendes encapsulationt."
A Student-es példában ez mind benne van.
- A hozzászóláshoz be kell jelentkezni
Mivel a Student példányok prototípusa a Person, ezért bármelyik Student felültudja írni bármikor a Person firstName paraméterét. Nem tudsz csinálni valóban privát változókat.
A leírás szerint: "In the previous example, Student does not need to know how the Person class's walk() method is implemented, but still can use that method; the Student class doesn't need to explicitly define that method unless we want to change it. This is called encapsulation, by which every class packages data and methods into a single unit."
Baromira nem ez az encapsulation. Ez az öröklődés. Az encapsulation fogalmában benne van, hogy amit kell, azt elrejtem mások elől, mert csak és kizárólag a publikus interfészem az, ami fontos. Nem az az encapsulation, hogy data + methods = single unit.
Ha megengeded, idézném a Wikipediat.
"Encapsulation is the packing of data and functions into a single component. The features of encapsulation are supported using classes in most object-oriented programming languages, although other alternatives also exist. It allows selective hiding of properties and methods in an object by building an impenetrable wall to protect the code from accidental corruption."
Hol van itt selective hiding?
- A hozzászóláshoz be kell jelentkezni
"Nem az az encapsulation, hogy data + methods = single unit."
Pedig ez nagyon olyasmit jelent: "Encapsulation is the packing of data and functions into a single component."
A következő mondatban ráadásul azt írja, hogy a legtöbb OOP támogatja. Hoppá! Lehet OOP encapsulation nélkül is?
Ráadásul a JS még a selective hiding-ot is támogatja
Egyébként innentől én már kiszálltam, mert ez már nagyon off.
- A hozzászóláshoz be kell jelentkezni
Ismerem a hivatkozott oldalt, az egész Good Parts könyvet ismerem, és tele van hackekkel, hogy emuláljanak egy olyan OOP-t, amire a nyelv önmagában nem képes (lásd a
var that = this;
típusú hackeket), ahogy ezt Crockford meg is jegyzi: " This is a workaround for an error in the ECMAScript Language Specification which causes this to be set incorrectly for inner functions."
"Private methods cannot be called by public methods. To make private methods useful, we need to introduce a privileged method."
Amikor ilyen hackelésekre szükség van, az pont azt jelenti, hogy ez a nyelv nem OOP nyelv. OOP-ben ezek by default adottak.
C-ben is lehet OOP stílusó kódot írni, lásd GLib, GObject és társai, de attól még nem lesz OOP nyelv.
- A hozzászóláshoz be kell jelentkezni
Anélkül hogy megnéztem volna a példát, tudsz csinálni information hiding-et:
function MyClass() {
var firstName;
this.getFirstName = function() {
return firstName;
}
this.setFirtsName = function(fn) {
if(typeof fn === "string") {
firstName = fn;
}
}
}
- A hozzászóláshoz be kell jelentkezni
"A W3C szerint is van REST compliant web service"
Mint írtam vala: a "web services" az nem "Web Services", de a "Web Services" az egy fajta "web services".
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
- A hozzászóláshoz be kell jelentkezni
és ezek egyike sem "Web services" avagy "web Services" ;)
Egyébként igazad van, jobb ezt tisztázni.
Én amellett foglaltam állást, hogy a REST web service-ek is "web services"-ek, nem csak "Web Services"-ek azok.
- A hozzászóláshoz be kell jelentkezni
Fogalmilag nem egyről beszéltek... :)
A "Web Services" az röviden WS, szabvány, jól le van írva, ehhez tartoznak olyan fogalmak és szolgáltatások, mint a WS-A, a WSDL, a UDDI és a többi, eléggé strict ahhoz, hogy használható legyen M2M kommunikációra.
A "web services" pedig nagyjából a HTTP protokollon haladó bármi lehet, ami távolról nézve kicsit is RPC szerű, leginkább, de nem kizárólagosan az end user böngészője és a webszerver közötti kommunikációt takarja, semmiféle szabványa nincs...
- A hozzászóláshoz be kell jelentkezni
Ezaz. Attól, hogy van egy HTTP-n elérhető, URL-ekkel címezhető valamid, az baromira nem lesz web service.
ha meg igen, akkor MINDEN web service, ami HTTP-n van.
- A hozzászóláshoz be kell jelentkezni
"Attól, hogy van egy HTTP-n elérhető, URL-ekkel címezhető valamid, az baromira nem lesz web service."
De, az "web services" lesz, de nem lesz "Web Services"... :)
"ha meg igen, akkor MINDEN web service, ami HTTP-n van"
Minden, ami RPC szerű, igen, egy szimpla AJAX is...
- A hozzászóláshoz be kell jelentkezni
Nem kell még az a feltétel sem. Mint ahogy fentebb olvastuk, ha a kliensoldal fel tud dolgozni text/html MIME típust, akkor az az endpoint egy web service és kész.
"Csak a kiinduló URL cím kell, onnan lekérdezhető az adott erőforrás, illetve, hogy azon az erőforráson milyen műveletek érhetők el, és az erőforráshoz milyen más erőforrások kapcsolódnak. Minden erőforrásnak van típusa (mime type), ha a kliens ismeri az adott típust, akkor tud is vele dolgozni."
És persze jön ilyenkor a HATEOAS meg a többi buzzword és faszság. Aztán rájönnek a HATEOAS és társai korláatinak feloldásával, hogy újra feltalálják a SOAP-ot.
- A hozzászóláshoz be kell jelentkezni
Igen, én értelek, és végig a "web services"-ről beszéltünk, hogy azok tényleg "web services"-ek, vagy csak a "Web Services"-ek a "web services"-ek, a "web services"-ek meg valami mások, amiknek nincs nevük, csak marketing bullshit és el kellene tűnniük.
- A hozzászóláshoz be kell jelentkezni
"Csak a kiinduló URL cím kell, onnan lekérdezhető az adott erőforrás, illetve, hogy azon az erőforráson milyen műveletek érhetők el, és az erőforráshoz milyen más erőforrások kapcsolódnak. Minden erőforrásnak van típusa (mime type), ha a kliens ismeri az adott típust, akkor tud is vele dolgozni."
De rohadtul nem errol van szo. Nézzünk egy egyszeru b2b igényt, rendelést akarunk feladni. Első problema, mi legyen az URL?
Resrkft.org/orders/new?
Nem jo, hiszen az orders/new nem egy erőforrás, hanem egy szolgáltatás, ha oda PUT-al fel akarok tölteni egy dokumentumot, akkor, logikailag azt jelenti, hogy egy "New" nevű dokumentumot töltök fel. Persze, ez meg abszolvalhato egy /orders/sajatrendelesazonositom url-el. Persze, a gyakorlatban inkabb az első dominal, az is POST-tal, ami messze nem REST.
Nade haladjunk tovabb, egy rendelesrol szeretnénk visszaigazolást kapni. Most akkor az a PUT/POST-ra lesz valasz? Most akkor miben mas, mint a SOAP?
Na de azt mondod, hogy tudom az URL-t, akkor mar tudom hasznalni a REST-es servicet. Megis hogy? Honnan fogom tudni, hogy nekem a rendelést milyen struktúra szerint kell feladni? Egyaltalan azt, hogy XML vagy JSON vagy CSV? Annak milyen mezoi legyenek? Ezekre a REST-es webservice megoldások nem nagyon adnak valaszt. Ezzel szemben SOAP eseten nemhogy azt tudtam, hogy milyen üzenetek johettek/mehettek, de meg azt is, hogy milyen szolgáltatások álltak rendelkezésre. Plusz, nekem kódot kellett írnom, nem egy random XML/JSON/stb dokumentumot. (Attol az esetről tekintsünk el, amikor valaki hulye volt es a SOAP-bol annyit ertett meg, hogy XML, es XMLDocument-et kuldozgetett oda-vissza*)
* Bar tippre nagyon sokan csinaltak igy, ami miatt nem csodálkozom, hogy sokan kiakadtam a SOAP-tol, de ez nem a protokoll hibája.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™"
- A hozzászóláshoz be kell jelentkezni
A POST miért nem REST? Az pontosan arra való, ha valamiből újat akarsz létrehozni, akkor használd. Ezért nem idempotens, a GET, PUT, DELETE-tel ellentétben. Tehát simán küldesz egy új dokumentumot a Resrkft.org/orders/ címre POST-tal, ami ha 200-zal tér vissza visszakapod az új resource azonosítóját, amit ezután már elérsz a Resrkft.org/orders/{ID} alatt.
Visszaigazolás: na ez egy érdekes kérdés, szerintem alapvetően az egy GET pl. a Resrkft.org/orders/{ID}/confirmation címre, ami 200-zal tér vissza ha minden OK, valami más státusszal ha nem (opcionálisan a bodyban továbbítva további részleteket).
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Na, egyet nem láttam még , ami így működött volna. ;)
Viszont ezt el tudom fogadni érvként.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
az elsőre a válasz az, hogy post-olsz egyet a resrktf.org/orders-re, amire visszakapsz egy azonosítót, vagy akár az új objektumot is.
A WSDL hiányzik, ez egyértelmű. Cserébe viszont a fejlesztés baromira gyors, nem kell minden interface módosítás után egy full buildet csinálni. Valószínűleg azt mondanám, hogy amennyiben egy standard crud jellegű oldalt csinálunk házon belül, ahol viszonylag kevés az üzleti logika, akkor egy REST interface-t választanék, amennyiben viszont külső fél felé akarok interface-t biztosítani és/vagy elég bonyolult üzleti logikák vannak, akkor inkább a SOAP-ra szavaznék.
A REST egy technikai megoldás, megvan a maga helye. Ha B2B-t fejleszt valaki, akkor valószínűleg nem ez az ultimate megoldás. Bár ahogy nézegettem, már REST-hez is vannak WSDL like megoldások:
http://www.ibm.com/developerworks/library/ws-restwsdl/
http://stackoverflow.com/questions/840653/wsdl-vs-rest-pros-and-cons
http://bitworking.org/news/193/Do-we-need-WADL
Ez azért árnyalja egy kicsit a képet.
- A hozzászóláshoz be kell jelentkezni
Még annyi jutott az eszembe, hogy mivel az esetek kb. 99.9%-ban egy REST alapú interface-t böngészőből turkálunk, ezért ott pl. a JSON mint adatformátum baromira jó,
mert a böngésző kapásból átforgatja javascript objektumra, míg egy xml esetén egy rakás parsolás vár még ránk, ami ugye megint csak programozási effort. Bár ez nem
tartozik szorosan a WS vs REST kérdéskörhöz, de azért ez is egy szempont lehet.
- A hozzászóláshoz be kell jelentkezni
"mert a böngésző kapásból átforgatja javascript objektumra"
Max a developer toolok. Beírtam a böngészőmbe egy JSON file URL-jét, ugyanazt kaptam vissza, mint amit text editorban látok. :(
" míg egy xml esetén egy rakás parsolás vár még ránk, ami ugye megint csak programozási effort."
Az XML-t a böngésző XSLT-vel akár még szép HTML oldalba is tudja tördelni neked.
Másrészt SOAP esetén objektumokat kapsz, amit a framework már jó régóta beparzolt (mint ahogy a JSON-t is parzolja neked a frameworköd, amit böngészőnek hívsz).
- A hozzászóláshoz be kell jelentkezni
Szerintem arra gondolt, hogy ha Javascriptből hívod meg, akkor egyből javascript object-té alakítja.
- A hozzászóláshoz be kell jelentkezni
Tehát a framework (browser) elvégzi a parzolást. Mint egy SOAP framework is. Ujjé!
- A hozzászóláshoz be kell jelentkezni
Ha jól értem, a te elképzelésed az, hogy van egy harmadik fél, aki ad egy API-t, amit te java backend-ből jól meghívsz, majd pedig legenerálod a html kódot, amit a böngésző megmutat. Ez nagyjából a standard J2EE vonal, és bizony ezzel nincs semmi gond. Szép, jó, működik.
De van egy másik architektúrális megoldás, ami egy kicsit másként működik. Itt is van egy backend, viszont a frontend egy fullos kliens oldali alkalmazás, amit pl. GWT-ben (mi GWT illetve smartGWT-t használunk), AngularJS-ben, vagy tetszőleges más kliens oldali keretrendszerben van írva. Ez a frontend beszélget a backenddel egy REST interface-en keresztül. Szinte zéró oldalletöltés történik az egész alkalmazás életciklusa során, cserébe az adatok dinamikusan cserélődnek. Mivel a böngésző alapból kiválóan támogatja a JSON-t, ezért igen kevés efforttal nagyon látványos, alkalmazás szerű web-alkalmazásokat lehet készíteni.
- A hozzászóláshoz be kell jelentkezni
Hogy jön ide a HTML? HTTP-ről beszélünk. Nem kell ide HTML.
Van egy szerveroldali fél, aki ad egy HTTP interfészt.
SOAP esetében ad egy XML filet (WSDL), ez tartalmaz minden fontos információt az interfész szintaktikájával kapcsolatban. Fogok egy toolt, és generálok belőle egy osztályhalmazt, amin keresztül az interfészt teljesen transzparensen kezelhetem. És ezt bármely értelmes nyelvből meg tudom tenni. Nem JS, nem Java, nem akármispecifikus.
REST esetén a legjobb workflow, amit ki tudtam alakítani, de ez Java-only:
- JAX-RS interfész készítése, csak interface-ek + DTO-k (ebből lesz egy Maven artifact, ez lényegtelen). Ebből készül is egy Javadoc a nem-Java kliensek számára.
- A szerveroldal implementálja ezt az interfészt.
- A kliensoldal az interfészre proxy osztályokat generál (akár futásidőben, lásd Resteasy).
Így mind a szerveroldal, mind a kliensoldal elől el van rejtve a transzport mikéntje, a leíró csak és kizárólag az API-ban van (legelső artifact). Itt vannak az URL-ek, a methodok, a paraméterek átadási módja (query param, vagy a body része stb), a MIME típusok.
Sem a szerver, sem a kliens nem tudja, hogy ezek a teljesen technikai dolgok mik.
Ez ugye egy csak JAX-RS-sel, csak Javaban működő megoldás.
Ha iOS-es vagy Androidos kliens libet szeretnék, esetleg C#-osat, az nem megy.
És ennek semmi, de semmi köze a RIA-hoz, a single-page appokhoz, a Javascripthez. Ez most csak egy HTTP feletti interfész, amit feldolgozhat mobiltelefonon natív kliens, feldolgozhat UI-t nem tartalmazó C-ben írt daemon, stb. Hogyan jön ide a HTML?
Nem weboldalt csinálok, hanem alkalmazást, ami adatot cserél egy kiszolgálóval.
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
"Cserébe viszont a fejlesztés baromira gyors"
Kurvára nem gyors. Neked, maximum, kiszolgáló oldalról. Viszont nekem, hívó oldalról ez úgy néz ki, hogy amit eddig helyettem megcsinált egy IDE, ahhoz most csinálhatom kézzel a parseolást.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Scala-hoz például vannak nagyon könnyen használható lib-ek, amikkel nagyon egyszerű parsolni, az osztályok megadásán kívül egy sor, kb. így néz ki:
scala> import org.json4s._
scala> import org.json4s.jackson.JsonMethods._
scala> implicit val formats = DefaultFormats // Brings in default date formats etc.
scala> case class Child(name: String, age: Int, birthdate: Option[java.util.Date])
scala> case class Address(street: String, city: String)
scala> case class Person(name: String, address: Address, children: List[Child])
scala> parse(jsonStr).extract[Person]
amivel egy ilyen json-t be tudsz parse-olni:
{ "name": "joe",
"address": {
"street": "Bulevard",
"city": "Helsinki"
},
"children": [
{
"name": "Mary",
"age": 5,
"birthdate": "2004-09-04T18:06:22Z"
},
{
"name": "Mazy",
"age": 3
}
]
}
- A hozzászóláshoz be kell jelentkezni
Tehát kézzel parzolsz. saxus sem arra gondolsz, hogy JSON parsert írsz, hanem arra, hogy adsz egy WSDL-t, és csinálok belőle Java osztályokat mondjuk. pl. wsimport segítségével.
https://docs.oracle.com/javase/6/docs/technotes/tools/share/wsimport.ht…
Ezt a toolt 1x kell megírni, és validálni, hogy helyesen működik, utána biztos lehetsz benne, hogy bármely WSDL-hez korrekt és pontosan megfelelő Java osztályokat generál, amin keresztül teljesen transzparensen használhatom a Web Service-t (sőt, igazából nem is kell tudnom róla, hogy ez egy Web Service).
- A hozzászóláshoz be kell jelentkezni
Az osztályok létrehozását nem úszod meg, ha mindkét oldalt Te csinálod. Ha csak a klienst, akkor igen.
Én a generált dolgokat se nagyon szeretem, nem használhatod kedved szerint, nem módosíthatsz rajta, mert egy új generálás elrontja.
A kézzel parsolásnak az is előnye, hogy nem kell az egészet behúznod, ha nem kell.
Ismerem a WS-t, nekem is kell használnom, sajnos én általában a rossz oldalára kerülök, nem a kliens oldalára, lehet ezért is nem annyira kedvelem.
- A hozzászóláshoz be kell jelentkezni
Mily érdekes, hogy nem úszom meg az osztályok létrehozását, amiben a logikát implementálni kell. Ez azért eléggé triviális :)
- A hozzászóláshoz be kell jelentkezni
"Az osztályok létrehozását nem úszod meg"
Azért egyszer valahol mégiscsak definiálni kell az adatmodelled...
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Ha az interfész DTO-ra gondolunk, lehet azt direktben a WSDL-ben is definiálni, amiből osztályok generálhatók (Javanal JAXB, máshol más XML binding). De attól még a logikát meg kell valósítani valahol :)
- A hozzászóláshoz be kell jelentkezni
Rosszul írtam, elnézést!
Akkor nem úszod meg, ha objektumokba akarsz parsolni.
A JSon elég egyszerű formátum: számból, szövegből, logikaiból, dátumból, tömbből és map-ből áll. Ahhoz semmit sem kell csinálj, hogy ilyen adatszerkezetbe beparsold.
- A hozzászóláshoz be kell jelentkezni
Dehogy nem kell csinálni semmit. A JSON egy szöveges formátum. Ha abból tényleges számot akarsz, tényleges mapet, objektumot, ahhoz parzolni kell. Csak te elfelejted, hogy ezt megteszi helyetted a runtime, ezért azt hiszed, hogy nem kell parzolni.
- A hozzászóláshoz be kell jelentkezni
Még egy utolsó gondolat a generálásról.
Pár évvel ezelőtt nagyon szerettem a Java-t, (még most is kedvelem azért), ilyennek láttam egy ideális stacket: alkalmazásszerver (tomcat, jboss, ...), spring (esetleg j2ee), jpa (mondjuk hibernate-tel), SOAP web service, esetleg még egy-két framework/lib a GUI-hoz is.
Aztán kezdtem megismerni más dolgokat is, pl.: Scala, funkcionális programozás, Play/Spray framework, Akka, Go lang, micro services.
Azt kellett látnom, hogy amit annyira jónak gondoltam lehet, hogy mégse annyira jó, hiszen van helyette sok esetben sokkal egyszerűbb alternatíva.
Csak egy példa. Java osztály létrehozásnál milyen nagy segítség, hogy könnyen, egyszerűen le tudom generáltatni a getter/setter-eket. Nagyon jó! Aztán Scala-ban azt kellett látnom, hogy ott meg nem kell legeneráltatni, az egy soros class definícióban meg tudom adni, hogy mihez legyen get, mihez set.
Ebből csak azt akarom kihozni, hogy nagyon sokszor az ilyen és hasonló tool-ok, amik "segítenek" legenerálni dolgokat, azokra sok esetben nem is lenne szükség, ha más dolgokat vagy máshogy használnánk.
Gondolatébresztőnek ajánlom mindenkinek "The Art Of Simplicity by Dr. Venkat Subramaniam" videót.
- A hozzászóláshoz be kell jelentkezni
Kapcsolódik: http://projectlombok.org/
- A hozzászóláshoz be kell jelentkezni
Kapcsolódik: https://msdn.microsoft.com/en-us/library/bb384054.aspx
Arról nem is beszelve, hogy mennyivel jobb, hogy logikailag meg van kulonboztetve az, hogy mi a property es mi egy metódus, ha esetleg reflectiont kell hasznalni.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
" Java osztály létrehozásnál milyen nagy segítség, hogy könnyen, egyszerűen le tudom generáltatni a getter/setter-eket."
Ha azok a getterek/setterek nem csinálnak semmit, nincs bennük logika, csak egy return that illetve that = param utasítást tartalmaznak, akkor semmi szükség rájuk. Helyettesítsd őket publikus adattagokkal, hiszen pontosan ugyanannyit érnek.
Ha használsz mást is (pédául property listenereket, lazy initet), akkor a gettert és a settert máris nem tudod generáltatni, mert üzleti logika van benne. És akkor Scalaban is ugyanott vagy, mint Javaban.
Jó dolog a konvenció, ismerem a Playt, az Akkát, azonban nem szabad elfelejteni, hogy az a legrosszabb, amikor valaki megismer egy ilyen lightweight frameworköt, és utána mindent ezzel akar megoldani, mert ez az ultimate eszköz.
Van ami nem oldható meg velük hatékonyan és egyszerűen. Van, amire meg jók. De hát ugye, akinek kalapácsa van, az mindenhol szöget lát.
- A hozzászóláshoz be kell jelentkezni
Kivéve, ha JavaBean-t csinálsz, akkor konvencionálisan getterekkel és setterekkel lehet hozzáférni az adattagokhoz. Mondhatjuk azt (bár szerintem ez így sehol nincs specifikálva), hogy egy java-s "property" áll egy privát adattagból, egy opcionális publikus getterből és egy opcionális publikus setterből.
- A hozzászóláshoz be kell jelentkezni
Csakhogy a JavaBean-ek nem csak abból állnak, hogy publikus a getter meg a setter és ez egy property. Abból is állnak, hogy lehet property change eseményekre hallgatni, tehát ami igazi JavaBean, ott van logika a getterben és setterben is.
http://docs.oracle.com/javase/tutorial/javabeans/writing/properties.html
Péládul bound propertyk, indexed propertyk, constrained propertyk.
A JavaBean nem DTO. A sima, publikus,semmit nem csináló getter/setter csak arra jó, hogy reflection-nel meghatározd a lehetséges propertyk halmazát. De amúgy káros dolog.
- A hozzászóláshoz be kell jelentkezni
"Ha azok a getterek/setterek nem csinálnak semmit, nincs bennük logika, csak egy return that illetve that = param utasítást tartalmaznak, akkor semmi szükség rájuk. Helyettesítsd őket publikus adattagokkal, hiszen pontosan ugyanannyit érnek."
A publikus adattagok eléggé szembemennek az OOP alapelveivel, még a protected is kérdéses.
- A hozzászóláshoz be kell jelentkezni
Ha a gettered/settered SEMMIT nem csinál, csak visszaadja, illetve bármiféle ellenőrzés nélkül beállítja az adattagod értékét, akkor az az adattagod ugyanúgy publikus, csak nem vallod be.
- A hozzászóláshoz be kell jelentkezni
ezzel egyet kell hogy értsek...
- A hozzászóláshoz be kell jelentkezni
(Az állításomban ez az eset is benne volt, hogy generálhatod az összes getter-t setter nélkül. Erre meg semmiképp sem jó megoldás a publikusság.)
Nem ugyanúgy publikus (, de az igaz, hogy a setter-ek általában is nagyon károsak, hacsak lehet, legyen minden immutable)
Pl.:
1. Leszármaztatásnál tudom szűkíteni a működését,
2. refaktorálás nélkül tudom szűkíteni a működését, pl. belerakok egy feltételt.
- A hozzászóláshoz be kell jelentkezni
mint írtam, akkor érdemes leginkább REST interface-t használni, ha közös csapat fejleszti a backend-et és a frontend-et. De ugye itt megint fontos, hogy hol van ez az interface. Egy frontend (kliens oldali webalkalmazás) és egy backend között (pl. restlet), vagy pedig egy harmadik fél rendszere (pl. számlázórendszer) és a mi backend kódunk között.
De a mostani kódunkban tudod mennyire parsolás van? Közel 0. Nem kell semmit se parsolnom, van egy json adatforrásom pl. http://xxx.com/rest/persons, és van egy smartgwt táblám kliens oldalon, és a táblának beadom hogy a következő oszlopok vannak (name, age, etc.) és kapásból mutatja az elemeket. Sőt, azt is kezeli, hogy ha módosítok egy sort, automatikusan küldi a megfelelő update-et.
- A hozzászóláshoz be kell jelentkezni
Azaz nem te csinálsz parzolást, hanem a frameworköd (smartgwt). Ugyanúgy, mint SOAP esetén :) Mily érdekes.
Te tényleg nem tudsz elvonatkoztatni attól, hogy a kliensoldalon a segged alá tolnak egy csomó technológiát, és úgy már milyen egyszerű a dolog.
"mint írtam, akkor érdemes leginkább REST interface-t használni, ha közös csapat fejleszti a backend-et és a frontend-et."
Ennek inkább a megfordítása igaz: a REST interface akkor működik további utánajárás nélkül, ha közösen fejlesztik a BE és FE kódokat. De még akkor is sok a szívás. Tapasztaltam, használtam WS-t és REST-et is. A WS kód WSDL-ból használva elsőre ment élesben, úgy, hogy az ellenoldali fél implementációját nem is tudtuk tesztelni sem előtte. Csak a WSDL volt.
- A hozzászóláshoz be kell jelentkezni
Igy van, de miért is kellene elvonatkoztatnom? A kliens oldalon van egy technológia, amivel gyorsan tudunk fejleszteni, az meg kiválóan működik együtt a REST interface-szel (egyébként menne WSDL-lel is), szép, egyszerű, tiszta kódunk van, minden erőforrásnak megvan a helye, ráadásul együtt fejlesztjük a BE és az FE kódot (a BE ráadásul 95%-ban plsql hívásokat illetve view-kat használ) A standard REST/JSON alapú megoldásnál tökéletesen látom, hogy milyen erőforrásra milyen kérések mennek, mi a content, egyszerű, világos, zavaró elemektől mentes. Akkor meg minek is kellene WSDL-t használnom? Mit nyernék vele?
- A hozzászóláshoz be kell jelentkezni
Ezen látszik, hogy te még nem láttál olyan szoftvereket, ahol nem csak FE-BE van, hanem mondjuk 6-10 rendszert (mondjuk mindegyik különböző vendortól) kéne integrálni, hogy egy adott szolgáltatást megvalósítsanak. Ez azért vállalati környezetben egy eléggé sokszor előforduló probléma, amit meg kell oldani. Ilyenkor az ember szereti, ha a mechanikus feladatokkal (a transzportrétegekkel, a hozzá tartozó interfészekkel) nem kell sokat törődni, hanem a lényeggel lehessen foglalkozni. Ugyebár létezik az ESB, SOA és sok más TLA. Nem véletlenül. Amikor ilyen dolgokat kell csinálni (na meg úgy általában bármikor amikor mechanikus dolgokat kell csinálni), eléggé kényelmes a gépre bízni azt, ami automatizálható. Például jó leírókat használva az egyes interfészek jól elrejthetők a lényegi kód számára. Az üzleti logikának nem is kell tudnia, hogy egy adott objektum, amin műveletet végzett, honnan ered: valamely message queue üzenetének deszerializált formája, HTTP-n jött JSON formában, valamely XML-RPC forrásból jött, netán adatbázisból. Nem kell tudni, sőt, nem szabad tudnia.
Vagy ugye te sem azt mondod, hogy egy helyen adtok ki SQL utasítást, és dolgoztok fel bejövő HTTP query paramétereket? Az ilyen, eléggé szorosan csatolt (tightly coupled) architektúra eléggé rugalmatlan, nem tudod benne könnyen lecserélni a DB-t, lecserélni a transzportot (mi van, ha interfészelni kell XML-RPC-vel a jövőben? Akkor újraírtok mindent?). Nem véletlenül kell az üzleti logikát, az interfészeket, a transzportokat elkülöníteni egymástól.
- A hozzászóláshoz be kell jelentkezni
Mint mondtam, vannak olyan rendszereink, ahol máshogy van a kapcsolat. Ezek más rendszerek, azokra az a fajta megoldás a kényelmes és hatékony.
Adatbáziskezelőhöz tightly coupled rendszer: már ne haragudj, ezt az elméleti érvet sokszor hallottam, de szerintem ez egyszerűen nem igaz. Nagyon ritka az az eset, amikor adatbáziskezelőt kell cserélgetni egy rendszer alatt. Persze vannak helyzetek, pl. portál rendszer, aminek több különböző adatbáziskezelővel kell futnia, de egy custom rendszernél ilyen a legritkább esetben történik. Ha lépés van, akkor jelen esetben postgresql-ről valami nagyobb rendszer felé történne, de a plpgsql függvények jórészt csont nélkül adaptálhatóak. Transzport réteg dettó: standard HTTP request/response megy a frontend (böngészőben futó alkalmazás) és a backend (restlet + dao kód) között. Mégis mi a nyavaját kellene kicserélni rajta?
- A hozzászóláshoz be kell jelentkezni
"Nagyon ritka az az eset, amikor adatbáziskezelőt kell cserélgetni egy rendszer alatt."
Ez valóban ritka eset, ennél sokkal gyakoribb, amikor az adatforrásaid különféle adatbázisrendszerekből jöhetnek. Például integrálnod kell MSSQL, MySQL és Oracle adatforrást is az alkalmazásodban. Custom rendszereknél ilyen nagyon gyakran van.
- A hozzászóláshoz be kell jelentkezni
Szakadj már el a webtől, van egy egész szép nagy világ azon kívül, ahol szoftverek kommunikálnak szoftverekkel.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Oké, akkor fussunk neki mégegyszer. Ti azt hozzátok fel érvként, hogy CSAK a SOAP a jó, mert .... erre lett egy csomó érv hozva. Erre én rámutattam, hogy bizony vannak
helyzetek, ahol a SOAP iszonyatosan kényelmetlen, és szükségtelen, és nehézkessé teszi a fejlesztést, és ugyanazt a problémát jóval egyszerűbben és gyorsabban meg lehet
oldani. Ennyit mondtam, nem többet. Teljesen aláírom, hogy vannak helyzetek, ahol a SOAP szinte az egyedüli korrekt megoldás. Akkor azt kell használni. Vannak más helyzetek,
ahová meg nem való. Oda meg nem kell használni.
De ez mindig egy architekturális döntés eredménye. Ugyanúgy, hogy websocketet, vagy más megoldást használunk-e kétirányú kommunkációra webböngészőből Pl. pár napja lőttünk össze egy lokális alkalmazásként futó rfid író/olvasó DLL-t egy weboldallal, nem kellett hozzá se java applet, se activex, se flash. Böngésző kapásból tudta.
- A hozzászóláshoz be kell jelentkezni
Sehol nem írtam, hogy CSAK SOAP.
Megvan a helye a pure JSON-over-HTTP interfészeknek is, akár RESTként vannak megvalósítva, akár procedurálisan.
Pont ilyen a webes kliensek helyzete. Mi is integrálunk ilyen végpontot az üzleti logikához.
Ettől függetlenül ez csak azért van így, mert a kliens egy weboldal, ami ezt tudja hatékonyan kezelni.
Viszont egy BE alkalmazás meg nem tudja hatékonyan kezelni (úgymond amikor két BE beszélget egymással).
Mivel ez is sokszor HTTP (mert dokumentumorientált, kérés/válasz alapú transzport kell, ezért nem találunk fel újat a TCP felett), sokan erőltetnék itt is a RESTful JSON-over-HTTP-t, hiszen ha HTTP, akkor JSON és RESTful interfész. Nem JSON-over-HTTP-t használunk, mert elesünk egy csomó olyan dologtól, ami kényelmes, például az egyértelmű, mindkét fél számára gépileg feldolgozható interfészleírás, a sok egyéb WS-* szabvány, amit mindkét fél ugyanúgy beszél stb. BE-BE kommunikációból általában több van, mint BE-kliens kommunikációkból (már csak azárt is, mert általában az, ami a kliensoldalon egy műveletnek látszik, az BE oldalon több rendszer együttes működésének eredménye). Ezért fontos az, hogy vannak eszközök, szabványok.
Majd a RESTful JSON-over-HTTP is el fog oda jutni, hogy lesznek szabványos interfész leírók, lesznek szabványok service discoveryre stb.
Csak ezt a szakma egyszer már megoldotta RPC esetén, ez lett a SOAP. RESTful esetre is lehetne ilyet csinálni, gányolás helyett. De nincs. Ezért inferior a RESTful JSON-over-HTTP a SOAP-hoz képest. Erről szól ez a szál.
- A hozzászóláshoz be kell jelentkezni
De ez teljesen egyértelmű, hogy két BE közé épeszű ember nem húz REST interface-t, mert oda nem való. Vagy nem értem a problémát :)
- A hozzászóláshoz be kell jelentkezni
Kivéve, ha az egyik vendor felülve a bandwagonra azt mondja, hogy bocs, az én szolgáltatásom RESTful JSON-over-HTTP módon érhető el, mert modern, nagyszerű és ez a legjobb (hiszen minden kliens web, ugye? :D).
Amikor nem te diktálod azt, hogy mit kell integrálnod, hanem odaadják, hogy na, akkor itt ez a RESTful interfész ehhez a 3rd party szolgáltatáshoz, használjuk, péntekre működjön, akkor pedig anyázol.
Nem minden szoftvert írsz te sem. Persze tudom, abból indulsz ki, hogy a BE és a FE egy csapat, de nem. Mondjuk úgy, a BE az 6-7 csapat, akikből van, aki dobozos szoftver ad, olyan interfésszel, amilyen. Oldd meg az integrálását gyorsan és pontosan.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
"Content-Type: application/vnd.example.coolapp.apiIndex-v1+xml"
"there are few standards for the format of the response of an OPTIONS call, but I went with a custom response body for the API to show a useful example"
Minden custom, minden egyedi. Ehhez persze nem lehet toolokat építeni, minden szart kézzel kell csinálni. Bravó!
Az egyedi MIME típusok helyett (application/vnd.example.coolapp.session-v1+xml) miért rosszabb a SOAP schema használata? 1-féle schema, 1 féle MIME típus. Helyette van n MIME típus stb. Ráadásul Schema nélküli XML-ek. Csodás. Ez aztán a quality!
- A hozzászóláshoz be kell jelentkezni
Szerintem próbáljunk meg különbséget tenni a "web services" és a "Web Services" között, mert külön fogalmakat takarnak. Sokat segít a megértésben...
- A hozzászóláshoz be kell jelentkezni
Egyáltalán nem ugyanarra való, csak sokan a REST-nek a lényegét sem értik ugyanúgy, mint a SOAP-nak a lényegét.
Kedvencem, hogy nemrég egy partnerünk áttért SOAP-ról egy ASP.NET WebAPI-s REST szarra, ahol
a) POST-al megy minden
b) XML-eket kapok/küldök
b.1) Amit kézzel kell építenem, ovlasnom
b.2) Validálást már nem is említettem.
c) Még csak közelíteni sem közelít ahhoz, amiről szólna a REST, hanem egy RPC van a háttérben valójában.
Ezzel szemben a régi SOAP-os cucc esetén megetettem a VS-el a WSDL linket (az IDE bármely random kedvenc IDE-re lecserélhető, vimfanoknak ígyjárás), az legenerált mindent, nekem csak annyit kellett csinálnom, hogy lepéldányosítottam a BlaBlaClient-et és meghívtam rajta egy függvényt, majd visszaadta az adatot. Osztályokban.
De most mennyire jó, hogy ugyanezt csinálhatom kézzel...
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Na igen, ilyen az, amikor egy procedurális interfészt erőltetnek dokumentum (REST) stílusba, mert az a menő.
- A hozzászóláshoz be kell jelentkezni
IDE WADL-lel megetet, mindent legenerál, kliens példányosít...
amennyire tudom REST ügyben Javahoz több tool van, mint C#-hoz.
- A hozzászóláshoz be kell jelentkezni
"WADL was submitted to the World Wide Web Consortium by Sun Microsystems on 31 August 2009, but the consortium has no current plans to standardize it."
Nem tudom mi kell még REST-hez amit az asp.net nem tud...
- A hozzászóláshoz be kell jelentkezni
Például ha mondjuk a REST dokumentumod szerializációja nem XML, hanem JSON, akkor a WADL nem tudja leírni az interfészt. A
representation
tag csak XML esetén értelmes IDE számára, amúgy pedig
doc
tagekkel írhatsz dokumentációt, ami vagy igaz, vagy nem, vagy teljes vagy nem, de azt nem tudja kódgenerátor feldolgozni.
- A hozzászóláshoz be kell jelentkezni
Mondjuk az ne zavarjon hogy a SOAP is webservice :)
- A hozzászóláshoz be kell jelentkezni
nem zavar
- A hozzászóláshoz be kell jelentkezni
-> Jason tusfürdőt rendelt a netről.
:)
- A hozzászóláshoz be kell jelentkezni
Fentebb láthatjuk, mi is a probléma az egész webalkalmazás ötlettel: túlburjánzott, gányolással teli világ, ahol sokszor még azt is képtelenek megmondani, hogy mi mit jelent. My 2 cents.
- A hozzászóláshoz be kell jelentkezni