Van értelme úgy fejleszteni egy php/javascript alapú applikációt, hogy http üzeneteket küldjön?
Úgy értem, hogy lényegében saját magának. Tehát megpróbálok bejelentkezni rossz jelszóval, egy ajax-os kéréssel, és küld egy 403-as kódot, és mellette persze az üzenettestet, hogy mi a probléma. A REST API nagyjából így működik, de ugye ott távoli kérések érkeznek.
Azért kérdezem, mert nekem minden egyes esetben, amikor nem 2-vel kezdődő http státuszkódot küldök vissza, szépen pirosan jelzi az errort a böngésző a konzolon. Ez még csak egy dolog, mert ugye erre van a promise-ben a reject, meg a try catch blokk, meg ezek a megoldások. A gond csak az, hogy egyik se működik. Tehát a http error kód minden egyes esetben szép pirosan megjelenik hibaüzenetként a konzolon. Miért?
Alap XMLHttpRequest objektumot használok, próbáltam gyakorlatilag az onerror metódustól elkezdődően (ami egyébként nem erre való) mindent addig, hogy magát a send metódust raktam be egy try catch blokkba, de minden egyes esetben hibaként jelezte, hogy küldtem egy http kódot.
Ez miért hiba? Ettől még a script nem hibás, hiszen ha az lenne, akkor nem működne. Egyébként megkapom a hibaüzenetet, és tudom is jelezni a felhasználónak, de borzasztóan idegesít ez a megoldás. El akarom tüntetni a console.error üzenetet a konzolról.
Szóval a másik kérdésem az lenne, hogy lehet eltüntetni a konzolról azt a tényt, hogy kaptam egy 500-as státuszkódot, vagy egy 403-asat, vagy bármilyen kliens vagy szerver hibát a szervertől? Az nem az én scriptem hibája, hogy a felhasználó nem megfelelő jelszót írt be az input mezőbe. Vagy békéljek meg vele, hogy ott lesz és kész?
Vagy találjak ki egy saját protokollt a hibaüzenetek visszaküldésére? Mi erre a megoldás?
válasza:200 -as küldéssel menjen vissza, egy JSON objektumba, ott pedig "status", "message", "content" -nek küldhetsz akármit amit js utána értelmez és feldolgozod.
Ha hibakódot küldesz vissza, az megjelenik a konzolba, mivel az általában http lekérés sikerességére vonatkozik.
Ez is egy megoldás, habár ha ténylegesen rest api-t fejlesztek, akkor ott olyan státuszkódot kell küldeni, ami megfelel az üzenet típusának.
Valahogy csak le lehet szedni azt a piros hibaüzenetet a konzolról...
válasza:"Vagy találjak ki egy saját protokollt a hibaüzenetek visszaküldésére? Mi erre a megoldás?"
Ne találj ki, erre van standard megoldás.
"Tehát a http error kód minden egyes esetben szép pirosan megjelenik hibaüzenetként a konzolon. Miért?"
Le kell kezelni az ajax kérés error metódusával. Ha látnánk a kódod ami a hibát dobja meg tudnánk válaszolni hol hibázol. Szóval töltsd fel egy kódmegosztóra a kódod.
Itt a teljes kód, egyébként typescript-ben van megírva. Az nem nagyon segít, ha magát a send metódust teszem try catch blokkba, és az XMLHttpRequest error metódusa pedig arra jó, hogyha egyáltalán nem tud valamiért végbemenni maga a kérés. Bármit csinálok, ott van a konzolon a hibaüzenet, akkor is, ha használom a promis catch metódusát, ami egyébként lefut. Tehát nem az a gond, hogy nem használható a kód, mert jól működik, ennek ellenére ott a hibaüzenet, hogy 403 forbidden, vagy 401 vagy akármilyen kliens vagy szerver hiba.
Az Url objektumban csak egy-két info van arról, hogy milyen url-en találhat a script.
válasza:Szerintem ezt egy picit túlbonyolítod. A TypeScriptnek van saját ajax implementációja, amivel könnyen tudsz bármilyen választ kezelni, nem kell ellenőrizgetned a válasz státuszait...
De ha mindenképp ragaszkodsz ehhez a megoldáshoz, nézz rá az XMLHttpRequest objektum eseményeire itt: [link]
Vagy használd az onerror függvényét, lásd itt: [link]
De egyébként összességében nem rossz a megoldásod, csak nagyon aprólékos és így nem használod ki a magas szintű TypeScript erejét.
válasza:Az onerror nem erre való, az csak abban az esetben működik, ha eleve már a kérés meghiúsul. Ez itt le van írva, kipróbálva se jó erre.
Értem én, hogy a http kérés független a javascript-től, és elég jól tudom, hogy hogy működik a http protokoll, csak miért nem mondjuk warn-t kapok error helyett? Szóval a lényeg az, hogy a scriptem nem hibás, de ha kapok egy kliens vagy szerver hiba státuszt, akkor az ott fog piroslani, tökmindegy mit csinálok.
Amúgy miért ne lehetne mondjuk egy try catch blokkal elkapni az ilyen hibát? Akár mondjuk így is le lehetne programozni egy böngészőt, mert ugye az interpreter a böngészőbe van építve. Azért megtévesztő ez az egész, mert a konzolra általában a szintaktikai vagy szemantikai hibákat szokta kiírni, vagy legalább is azokat is. De ez van, ha működik a kód, akkor lesz@rom, hogy piros lesz a konzol...
válasza:"csak miért nem mondjuk warn-t kapok error helyett"
Mert ezek nem warning szintű üzenetek hanem error szintű üzenetek, ez így van jól és nagyon megtévesztő lenne ha warning szintre hoznád. Láttam ilyen kódot ahol a success szintben jött vissza minden http válasz, had ne mondjak csúnyát milyen azt fejleszteni.
"Amúgy miért ne lehetne mondjuk egy try catch blokkal elkapni az ilyen hibát?"
Mert amit te akarsz az a legtöbb esetben aszinkron kérés a szerver felé. Itt nem fogod a http protokoll kéréseit elkapni a catch ágban, mert a kliens pont telibe sz*rja azt hogy mikor jön meg a hibás válasz és addigra a catch ágaid már rég végeztek a feladataikkal. Amit te akarsz azt kliens vagy szerveroldali validációnak nevezik, ez adja a warning szintű hibaüzeneteket vissza.
"elég jól tudom, hogy hogy működik a http protokoll"
Akkor használd az eszközeid a protokoll szerint, ne akarj alávágni magadnak és fejlesztőtársaidnak azzal, hogy fel akarod találni a spanyolviaszt...
További kérdések:
Minden jog fenntartva © 2024, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!