Érkezik a HTTP/2 támogatás a Google Chrome-ba, a SPDY röpül

Google

A Chromium fejlesztők bejelentették, hogy az elkövetkezendő hetekben fokozatosan bevezetik a HTTP/2 támogatást a Google 40-ben. A széles körben használt HTTP/1.1-hez képest a HTTP/2-ben komoly hangsúly volt a teljesítményen. Több olyan kulcsfontosságú funkció - multiplexing, header compression, prioritization stb. - is található a HTTP/2-ben, ami a nagyobb teljesítményt szolgálja.

Mivel ezen funkciók egy része a Chrome által támogatott SPDY-ben is megtalálható, a fejlesztők a HTTP/2 bevezetésével dobják a nem szabványos SPDY támogatást.

A bejelentés itt olvasható.

( log69 | 2015. 02. 10., k – 08:19 )

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 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."

( bra | 2015. 02. 10., k – 08:37 )

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 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 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.

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".

> 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).

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.

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.

" 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.

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.

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.

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".

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 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 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.

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...

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."

"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?

"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

( uid_6201 v | 2015. 02. 10., k – 14:46 )

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!

( uid_17784 | 2015. 02. 10., k – 15:09 )

A SOAP szopas.

Webservice (REST-JSON) kiraly.

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.

-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 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.

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).

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 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 :)

"É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 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?

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? :)

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.

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?

"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.

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.

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...

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.

"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 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).

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.

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.

"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).

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.

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.

"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™

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
             }
           ]
         }

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).

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.

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.

" 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.

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.

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.

"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.

(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.

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.

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.

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?

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.

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?

"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.

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.

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.

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.

"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!

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™

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.

( wachag | 2015. 02. 12., cs – 06:26 )

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.