PHP: "Egyéni" http metódust érdemes használni?
2020-01-29T22:13:16+01:00
2020-02-03T19:07:01+01:00
2022-07-20T16:51:59+02:00
  • Nem lehet egyebkent, hogy cocoya3 nem is gondolja ezt az egeszet komolyan, csak teged akar tornaztatni? :)
    Mutasd a teljes hozzászólást!
  • Hány http metódus parser támogat a metódusban paraméter átadást? Pld get helyett get19 get2085 és társai.

    A paraméterek átadására nem a metódus való, hanem a HTTP header-ök és a query paraméterek. (Igazából a path részben is átadhatod őket, a protokoll szempontjából az kb. ugyanaz.) Így nem csak egy paramétert tákolsz rá a meglevő protokollra, hanem tetszőleges darabszámút használhatsz relatíve jövőbiztos és bővíthető módon.

    Értelem? Lehetne prioritásba venni a http kiszolgálásokat.

    Konkrétan ha prioritást szeretne a kérő adni a kérésének, akkor használhatna egy "Priority" vagy hasonló nevű headert. Ha mindenképp fontos, hogy a kérés legelején legyen a prioritás, akkor meg lehet követelni az első query paraméterként is. (Ez mondjuk már hátráltatja a cache-elést, szóval nem feltétlenül éri meg meglépni.)

    Ha pedig annyira über-fontos a teljesítmény, hogy egy query string parsing se fér bele, akkor lehet neked nem is HTTP-re van szükséged. Ezen a ponton már feltalálhatod a saját protokollodat, aminek nem kell igazodnia holmi RFC-khez meg best practice-ekhez, és mindent feláldozhatsz a hatékonyságért.
    Mutasd a teljes hozzászólást!
  • Konkrét előny.

    Hány http metódus parser támogat a metódusban paraméter átadást? Pld get helyett get19 get2085 és társai. Meg lehetne valósítani.

    Értelem? Lehetne prioritásba venni a http kiszolgálásokat. A mai világ úgyis szereti a felhőzést, és annak bizony nagyon korlátos tud lenni a teljesítménye. Ráférne a felhő kiszolgálókra valami rate limiting lehetőség már http parsing szintjén. Nekem egyenlőre nincs olyanról tudomásom.
    Mutasd a teljes hozzászólást!
  • Szakmai kérdésre próbáltam szakmai választ adni. Azzal nem tudok mit kezdeni, hogy valamilyen vállalat belső politikai csatározásai miatt nem a szakmailag legjobb megoldás kerül implementálásra, hanem valami kompromisszumos. Én is nagyvállalatnál dolgozom, és igen, előfordul ilyen is.

    Konkrét előnyét még mindig nem sikerült mondanod a nem szabványos metódusoknak, de majd ha sikerül egyet megszülni, én szívesen meghallgatom.
    Mutasd a teljes hozzászólást!
  • > Épp csak elkezded nézni a tcp stream-et, parsingolod a legelejét, és máris el tudod dönteni, merre akarod tovább küldeni.

    Hogyne. Sőt igazából olyan HTTP igék is kellenének, hogy 'számlanyitás-belföldi-nyugdíjas-házaspárnak', meg 'szülési-szabdság-megállapítására-irányuló-kérelem'.

    Ha viszont a józan ész keretei között szeretnénk ugyanezt, akkor is van megoldás:

    POST /szamlanyitas/hazaspar/belfoldi/nyugdíjas.cgi HTTP/1.1 POST /szabadság/kérelem/szülési.jsp HTTP/1.1
    Mutasd a teljes hozzászólást!
  • Egyszerű technikai okok is lehetnek a háttérben. A header az üzenet legelején megy át. Épp csak elkezded nézni a tcp stream-et, parsingolod a legelejét, és máris el tudod dönteni, merre akarod tovább küldeni. Ha az útválasztáshoz szükséges paramétereket contentbe rakod, a teljes üzenetet cache-elned kell, mielőtt irányba állíthatnád.

    Kicsit olyasmi, mint a layer 4 kontra layer 7 routing. A layer 7 sokkal több erőforrást eszik. Kicsi teljesítményen persze az nem probléma, lehet akár layer 7-es load balancered is, mert miért ne adjunk a kényelemre? De ha emelkedik a teljesítmény igény, valamit akkor is tudnod kell adni, és a nagyobb teljesítményű cuccok csak gyengébb döntéshozó kapacitást tudnak adni.

    Egyébként vannak webes api felületek, amik még post-al sem vacakolnak, csak beteszik get-be a paramétereket, és dobnak json választ. A saját feladatukra tudnak abszolút okésak lenni azok is. Lásd Google / Facebook api-k példának.
    Mutasd a teljes hozzászólást!
  • Ami érveket felhoztál, az annak függvényében hátrány, vagy előny, hogy egy üzleti küzdelem mikrokörnyezetében ki hoz meg több áldozatot. Ha arról beszélsz, hogy történeti okok miatt van most egy kiforrott állapot, és annak is kellene maradnia, arra egy üzletember két kérdést fogalmazna meg. Ad1 pénzről beszélünk, vagy csak beszélünk? Ad2 ha pénzről beszélünk, te kitől kapod?

    * Nem tudsz (vagy nem könnyen tudsz) a service-ed elé extra rétegeket pakolni, amit más implementált

    Kontra a valaki más terméke az adott project környezet számára értéktelen.

    * Bizonyos nyelvekben és környezetekben nem tudod megvalósítani a nem szabványos metódusok szerver oldali kezelését

    Kontra azok a nyelvek és környezetek alkalmatlanok a dinamikus fejlődésre.

    * Ahol meg is tudod oldani, ott is jó eséllyel könnyebb megoldással kezelhető le a szabványos metódus, mint a nem szabványos

    Kontra üzletileg védhetőbb pozíció kiépítése a feladat, nem láblógatás.

    Persze lehetünk szakbarbárok is, csak az informatikát nézni szemellenzősen, és semmi mást, de vajon úgy fogunk jobban járni az utólagos statisztika tapasztalata szerint?
    Mutasd a teljes hozzászólást!
  • Viszont kategórikus "nem"-et mondani az előtt, hogy kiderülne, miért is akar valaki küzdelemre vállalkozni, garantáltan pénzt hagyna az asztalon minden esetben.

    Nem tudom, ki mondott itt kategórikus "nem"-et. Én azt mondtam, hogy nem látom értelmét. Ezen a ponton jöhettek volna érvek, amik felvázolják a dolog előnyeit. Helyette az jött, hogy hát igazából nincs hátránya, és erre válaszul mondtam példákat a hátrányára.

    Hogy ne legyen általános szájtépés, próbáljunk egy konkrét példát. Legyen a HR-es alkalmazott nyilvántartás egy REST service-ben. Ha Józsi adatait le akarom kérdezni, nem azt küldöm hogy "GET /employees/jozsi", hanem hogy "READ /employees/jozsi". Ha Józsi fizetését meg akarom változtatni, nem azt küldöm hogy "PUT /empoyees/jozsi", hanem hogy "UPDATE /employees/jozsi". Ha Józsit kirúgják, akkor nem azt küldöm, hogy "DELETE /employees/jozsi", hanem hogy "REMOVE /empoyees/jozsi", vagy esetleg "FIRE /employees/jozsi". Milyen előnyöm származik ebből a megoldásból? Hátrányát már láttuk, többek között:
    * Nem tudsz (vagy nem könnyen tudsz) a service-ed elé extra rétegeket pakolni, amit más implementált
    * Bizonyos nyelvekben és környezetekben nem tudod megvalósítani a nem szabványos metódusok szerver oldali kezelését
    * Ahol meg is tudod oldani, ott is jó eséllyel könnyebb megoldással kezelhető le a szabványos metódus, mint a nem szabványos
    Mutasd a teljes hozzászólást!
  • Ha már RPC-re használjuk a HTTP-t, miért nem tudjuk az összes opciót, paramétert és adatot a Content-be tenni, miért kell Header-be is belepiszkálni?

    Mecsoda kövület lehetsz már, ha a 90-es években ellőtt XML-RPC - Wikipedia-ből (SOAP, stb.) vagy a 2000-es években kitalált JSON-RPC - Wikipedia-ből akarsz ötleteket meríteni.
    Mutasd a teljes hozzászólást!
  • Ha már RPC-re használjuk a HTTP-t, miért nem tudjuk az összes opciót, paramétert és adatot a Content-be tenni, miért kell Header-be is belepiszkálni?
    Mutasd a teljes hozzászólást!
  • Az nem kérdéses, hogy küzdelemre kell majd számítania annak, aki újításokat akar bevezetni. És lehetünk éppen negatív alaphangon annak okán, hogy az utólagos statisztikák szerint mindig mindenki olcsóbban akarja megúszni, mint amibe kerül, aztán az informatikára szájal a sok hipszter olcsó jános a saját csórósága helyett. Néha tényleg fárasztó. Viszont kategórikus "nem"-et mondani az előtt, hogy kiderülne, miért is akar valaki küzdelemre vállalkozni, garantáltan pénzt hagyna az asztalon minden esetben. Azokban az esetekben is, amikor valamit össze lehetne hozni.

    Apropó csavarok. A minap rendezgettem elosztókat a konyhában, és az egyikben az egyik konnektor hely nagyon kellett volna +1-nek. De valami kosz úgy beleszorult, hogy szét kellett volna bontanom kitisztítani. Nosza láttam olyan csavarfejeket, amilyet még nem sokat. Ja, szitkozódtam éppen rajta, és kicseréltem az elosztót. De az végső soron nem azért történt, mert az egyik csavarfej rosszabb lenne, mint a másik, hanem mert az üzletben nem olyan csavarhúzókat árultak évek óta nagyon olcsón.
    Mutasd a teljes hozzászólást!
  • Nem kell ahhoz szabványosítani, hogy valaki a saját házatáján értelmezzen bármilyen http eljárást.

    Valóban nem. Szabványok azért léteznek, hogy különböző emberek által írt programok, meg különböző gyártók által gyártott dolgok együtt tudjanak működni. Például ha szabvány metódusokat használsz, akkor gond nélkül a webservice-ed elé pattinthatsz egy Varnisht vagy Squidet cache-elés céljából, vagy akár szerződhetsz egy CDN-nel, hogy az egész bolygón szétszórva legyenek cache-eid. Ha meg saját neveket adsz a szabvány műveleteknek, akkor minimum a konfigurációt kell túrni, meg a CDN üzemeltetőjével külön tárgyalni, hogy akkor ezzel mit is kell kezdeni.

    És ha böngésző nem supportolja, csak annál jobb.

    Hát még ebben sincs igazad. Csak a vicc kedvéért kipróbáltam a következő kis kódocskát egy fejlesztői konzolban, itt a prog.hu-s poszt író ablakban:

    x = new XMLHttpRequest(); x.open('MACSKA', '/'); x.send();
    A böngészőm gond nélkül elküldött egy "MACSKA / HTTP/1.1" kérést, amit a prog.hu úgy szolgált ki, mintha GET lett volna. A developer.mozilla.org ugyanerre 403 Forbidden státusszal válaszolt.

    Egyébként is édeskevés lenne biztonsági szempontból, ha valami csak az abszolút amatőröket tartja vissza a támadástól. Ha valami értékes, akkor a komolyabb támadók elől is meg akarod védeni, nem?

    Szóval igen, senki nem tart vissza tőle, hogy saját metódusokat használj, de továbbra se látom semmi előnyét, főleg ha a szabványos metódusoknak adsz új nevet. Kb. mintha a te házadban az összes csavar saját gyártású lenne, és csak a saját csavarhúzóiddal lehetne őket kicsavarni. Nem fog érte megbírságolni a rendőr, csak magaddal tolsz ki, amikor jönne egy szaki szerelni és az ő csavarhúzója nem lesz jó sehová.
    Mutasd a teljes hozzászólást!
  • Bocsi, hogy beszólok az ASP-re, de ha az nem képes egyedi metódusokat támogatni, majd a Micro$oft lesz szíves normálisabban megírni 
    Mutasd a teljes hozzászólást!
  • Bizalmas: még nem egyénit sem érdemes használni, a POST-on kívül.
    Mutasd a teljes hozzászólást!
  • Ott látom a veszélyét a dolognak, hogy lehet, hogy a webszerver nem fogja tudni kiszolgálni a nem szabványos HTTP-metódussal érkező kéréseket, mert mondjuk a fejlesztőik elkövették azt a hibát, hogy nem stringként kezelik, hanem csak a szabványos, beépített típusaikat támogatják. Ugyanez előfordulhat kliensoldalon is, hogy ők sem tudnak olyan kérést indítani, aminek a HTTP-metódusa egyedi.

    Például, ha megnézem az ASP.NET-et, az nem is támogatja az egyedi HTTP-metódusokat, így abban nem is tudsz ilyet csinálni.

    Egyébként itt van egy szép kis RFC az egyedi metódusokról: https://tools.ietf.org/html/rfc7231#section-8.
    Mutasd a teljes hozzászólást!
  • Oké, a get-re rosszul emlékeztem, nálad a pont 

    Hanem a melegvizet illetően szerintem csak túl kritikus vagy. Nem kell ahhoz szabványosítani, hogy valaki a saját házatáján értelmezzen bármilyen http eljárást. A lehetőség nyitott rá. És ha böngésző nem supportolja, csak annál jobb. Akkor tuti biztos nem javascript huszárok fogják hackelni a szerveredet, mert minimum bináris program kell majd hozzá, mint például az app-od almás portja.
    Mutasd a teljes hozzászólást!
  • Egykoron metódusok sem voltak, csak http kérés.

    Erre van valami forrásod? A legkorábbi fennmaradt HTTP specifikációban már az van, hogy a kérés a "GET" szóval kezdődik, tehát már ekkor bele volt tervezve a további metódusok lehetősége. Inkább úgy tűnik nekem, hogy kezdetben egy metódus volt, a GET, aztán később ezt a listát bővítették.

    Attól függően, milyen feladatokra célszerű üzemeltetésileg külön feldolgozókat létrehozni, idővel úgyis saját metódust fog kapni mindegyik.

    Ennek ellentmondani látszik, hogy évtizedek óta megvan a Web a szabvány metódusokkal (sőt, igazából GET/HEAD/POST metódusokkal, illetve manapság a CORS kedvéért az OPTIONS-szel), és a webservice-ek túlnyomó többsége ugyanúgy nem talál fel saját metódusokat, általában a GET, HEAD, PUT, POST, DELETE és OPTIONS bőven elég nekik.

    A feldolgozást nem csak a metódus alapján lehet irányítani különböző kódokhoz, hanem a metódus és az URL alapján is. (Úgy is egy sorban jön ez a két adat, nem ezen fog múlni a teljesítmény.) Ha a szolgáltatásodat ki lehet fejezni dolgok olvasása, írása és törlése alakjában, akkor a meglevő metódusok elegendőek lesznek: GET=olvasás, DELETE=törlés, PUT=létrehozás/felülírás, POST=létrehozás (meg minden más is lehet, ami a többibe nem fér be).

    Az nem a melegvíz újrafeltalálása, egyszerűen csak fejlődés.

    Azt azért te se gondolod komolyan, hogyha PUT helyett UPDATE metódust írok, vagy DELETE helyett REMOVE-ot, és a szemantikáján nem változtatok, akkor az nem a melegvíz újrafeltalálása

    Még ha valami koncepcionálisan teljesen új metódusról lenne szó (mit tudom én, MOVE, LOCK vagy SHARE), akkor még lehetne menteni, hogy ez csak fejlődés és új lehetőség, de a jó öreg CRUD műveletekre már van bejáratott megoldás.
    Mutasd a teljes hozzászólást!
  • Én a magam részéről nem látom hátrányát az új http metódusoknak. Egykoron metódusok sem voltak, csak http kérés. Aztán jöttek a get meg a post, hogy külön előfeldolgozókra lehessen irányítani a stream-et (azok a kulcsszavak vannak a stream elején). Attól függően, milyen feladatokra célszerű üzemeltetésileg külön feldolgozókat létrehozni, idővel úgyis saját metódust fog kapni mindegyik. Az nem a melegvíz újrafeltalálása, egyszerűen csak fejlődés.
    Mutasd a teljes hozzászólást!
  • Személy szerint nem látom értelmét. A REST egyik előnye, hogy mindenki ugyanazokkal a metódusokkal dolgozik, így a közbülső felek (proxy, cache, vagy akár valami vírusirtó) tudnak mit kezdeni a rajtuk átmenő forgalommal. Azon túl, hogy újra feltalálod a meleg vizet (PUT helyett UPDATE, DELETE helyett REMOVE), még mindent jól össze is zavarsz, ami esetleg szabványos metódusokkal tudna kezdeni valamit.
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Szeretném a véleményetek kikérni az egyéni http metódus alkalmazásáról.
    Tételezzük fel hogy van egy API-nk, ami kitud olvasni, írni és létrehozni. Alap esetben a POST, PUT, GET metódusok használata javasolt. 
    Viszont, ma találkoztam egy olyan feladattal, ami nem ezekre épül.

    #./api/termekek.php function router(){ $request_method = $_SERVER["REQUEST_METHOD"]; $postdata = file_get_contents("php://input"); $data = json_decode($postdata); switch($request_method){ case 'NEW': //data feldolgozása return(0); break; case 'UPDATE': //data feldolgozása return(0); break; case 'REMOVE': //data törlése return(0); break; default: return($data_json); break; } }
    A fenti kódsor kezeli a kéréseket a szerver felé (JSON formátumokat fogad és azokkal is válaszol). Egyetlen egy POST metódussal találkoztam és az is a file feltöltés végett. (A fájl feltöltés kíváncsiságból teszteltem "egyéni" metódussal is és nem működött). Tény, hogy asszociáló a metódusok nevei az általuk végzett feladatra, de érdemes e ezeket használni? Továbbá egy REST API létrehozásához érdemes e egy hasonló switch - case szerkezetre építkezni?

    Köszönöm előre is a válaszotokat!
    Mutasd a teljes hozzászólást!
abcd