XMPP, RTSP, IMAP/SMTP
Van ezekkel egy szintű protokoll, amibe mindent be tudsz ágyazni: HTTP. A három felsorolt protokoll egészen fix adatmodellel dolgozik (még az XMPP a kivétel, ott a különböző XEPekkel változik folyamatosan az adatmodell - csak aztán sok sikert a minden szükségesnek ítélt kiterjesztést támogató szerver és kliens kereséséhez...), a vásárlásos példádnál maradva a protokoll semmit nem mond arról (mert nem az a dolga), hogy a "Csá, kéne tizenötezet műanyag basz. Köszi, B." szövegű leveled akkor legyen vásárlás.
Miért ne lehetne egy IMAP-hoz hasonló protokoll internetes vásárlásra?
Tessék, ülj le és csináld meg. Vagy csak kezdj el egy specifikációt összerakni. Felőlem mehet HTTP transporton JSON-nal. Sok sikert hozzá. Kb. pár másodperc gondolkodás után rájössz, hogy egész más adatmodell kell egy consumer to consumer (ebay), egy business to consumer (amazon, aliexpress, ebay) és egy business to business (alibaba) vásárláshoz. Az első kettőhöz illik online (értsd: azonnali, tranzakción belüli) fizetést csinálni, a harmadiknál a legtöbb cég kiröhögne, ha a "úúú és kártyával kelljen fizetni" tétel megjelenik a követelményeid között. Aztán persze a termékleírásoknak valamilyen strukturált formában kellene közlekedniük, különben ott tartunk, hogy az egyik mark-up nyelvet lecseréltük egy másikra és van egy nagy adathalmazod, amiben kb. fulltext tudsz csak értelmesen keresni (ez még az ebay-nek sem igazán megy, nézd meg időnként a bal oldali sávban a szűrési lehetőségeket). Aztán persze jönnek a különböző payment processorok (PayPal), mert Hajbazer (tm) natív kliens mániája miatt nem fogom minden jött-ment site-nak megadni a bankkártya adataimat, továbbra is szeretném csak a PayPalnál tárolni azokat (whoops, még egy API, amit az elfogadók [Paypal, google pay, apple pay, lófasz pay] torkán le kell nyomnod és a kliensben implementálnod, adatmodellel mindennel, vissza az asztalhoz specifikálni). Aztán persze ha nem valami létező, TLS-t támogató transport protokollt használsz (pl. HTTPS), akkor kezdhetsz agyalni a titkosított átvitelen, még HTTPS esetén is gondolkodhatsz az authentikáción is stb.
Persze, le lehet ülni, lehet csinálni tök jó protokollokat az auth-tól kezdve a shipping providereken (én pl. nem szeretem, amikor az eladó tudja a címem, jobb lenne, ha azt egyedül a szállító cég kapná meg, ők csak adjanak egy azonosítót, amit a feladó ráragaszt a dobozra, mielőtt átveszi tőlük a szállító, majd utólag ráteszik a címet, ha másik szállítóhoz kerül [pl. dán posta átadja a magyar postának, de egy DHL "házon belül" megoldja])... azon túl, hogy soha nem végeznél vele, mert mindig lenne olyan use case, amire még alkalmatlan a megoldásod, több verzió kellene a protokollból (az IMAP is már a 4.-nél tart és a mai napig hozzá kell piszkálni időnként (egyébként ha már mail access és protokoll: az Exchange ActiveSync protokoll elkövette ugyanezt a hibát, nagyon részletes adatmodellt definiált... és a tizenhatodik verziónál jár, pont a fentiek miatt: megváltozott követelmények, folyamatosan változó adatmodell és úgy általában a kliensek képességeihez igazítják időnként [20 éve a mobileszközök kicsit más képességgekkel rendelkeztek és máshogy nézett ki az e-mail is...]).
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)