7,540
edits
Changes
→Áttekintés
==Hibakezelés==
===Áttekintés=Response objektum előállítása==Ez egy sarkalatos pontja a REST interfész implementációnak, ugyanis a kliensnek minden esetben vissza kell adni egy szabványos REST választ, ahol hiba esetén lehetőleg megmondjuk, hogy mi történt, tehát minden hibát le kell valahogy kezelni. Ezen felül előfordulhat, hogy hiba esetén más objektum típussal szeretnénk visszatérni, mint a boldog ágon. A @GET/POST/PUT annotációkkal ellátott metódusoknál a visszatérési objektum típus meghatározására két lehetőségünk van.
* Ha rest metódusnak egy POJO a visszatérési értéke (vagy egy abból képzett típus) akkor sikeres futás estében, a metódus visszatérése után a JAX-RS ebből automatikusan REST választ fog generálni, a POJO-t JSON/XML-re fogja konvertálni, és be is állítja a HTTP státuszt, nekünk ezzel ebben az esetben semmi dolgunk. Viszont több okból is meg van kötve a kezünk: Ha a metódus sikeresen elfut, akkor a JAX-RS ezt mindig sikeres futásnak fogja tekinteni, és a HTTP státuszt mindig 200-ra fogja állítani, nem tudunk beavatkozni a válasz elkészítésébe.
* Ha a service metódusnak nem egy POJO a visszatérési értéke, hanem a javax.ws.rs.core.Response, akkor teljes kontrolunk van a válasz összeállításában, viszont mindent mind sikeres, mind sikertelen ágon nekünk kell kézzel a válaszba belerakni a megfelelő response JAVA objektumot és beállítani a HTTP státuszt. <br>
https://dennis-xlc.gitbooks.io/restful-java-with-jax-rs-2-0-en/cn/part1/chapter7/complex_responses.html
Alább láthatunk egy példát a teljesen manuális response összeállítására. Ha a header-t és azon belül a sütiket is állítani akarjuk, akkor muszáj ezt a megközelítést használni.
<source lang="java">
@GET
}
</source>
A státuszt kétféle képen határozhatjuk meg A Resonse osztálynak többféle metódusa van, ami beállítja a státuszt: ok=200, created=204 ..., vagy mi állítjuk be kézzel: .status(int)
===Egyedi Response objektum exception kezeléssel=== azt fogja JSON/XML struktúrára mappe-elni automatikusan Ez egy sarkalatos pontja a JAX-RSREST interfész implementációnak, és ugyanis a HTTP . Ennek az az előnyekliensnek minden esetben vissza kell adni egy szabványos REST választ, hogy a válasz automatikusan előáll a boldog ágon. Azonban ahol hiba esetén nem tudunk más objektum típust használni. Megoldás lehetlehetőleg megmondjuk, hogy olyan univerzális választ definiálunkmi történt, amiben van egy ErrorMessageResponse paraméter istehát minden hibát le kell valahogy kezelni. Úgy fogjuk megoldani, amit csak hogy hiba estén töltünk kiesetén egyedi response objektumot dobjuk, és akkor nem különbözik a válasz típusa sikeres és sikertelen futtatás estén. Ha viszont különböznie kell, akkor két lehetőségünk van: ** Hiba hogy hiba esetén egy saját Exception-t dobunk, amit egy Exception provider-el feldolgozunk, és egyedi hiba objektumot készítünk belőle a válaszba. ** A service metódusunknak nem egy POJO a visszatérési értéke, hanem egy javax.ws.rs.core.Response, amibe mi állítjuk ha java csak azt tudjuk definiálni, hogy mi legyen a válasz típusa happy ágon, mikor a kérést rendeltetés szerűen ki tudta szolgálni a szerver, tehát a HTTP státusz kódja a válasznak a 200-as tartományba fog esni. Ha van visszatérési érték, akkor feltehetően ez 200 lesz, ha nincs, akkor 204, ezt automatikusan kezeli a JAX-RS. Viszont mi van akkor ha hiba történik a feldolgozásban. A kliensnek semmilyen körülmények közözz nem szabad egy java stack trace-t visszaadni, minden körülmények között egy szabályos REST választ kell visszaküldeni, ahol a HTTP státusz megfelelően ki van töltve, és lehetőleg egy egységesített ERROR objektumban benne van a hiba leírása. * 400-as hibák: A feldogozás az input adatok miatt nem sikerült, pl hiányzik valami, vagy nincs joga a kliensek a kérést végrehajtania * 500-as hibák: Az input paraméterek megfelelőek voltak, de a szerver oldalon nem várt hiba történt. (pl nem tudtunk egy szükséges háttérrendszerhez csatlakozni) Egy java metódusból úgy lehet az előre definiált visszatérési értéken felül más típusú választ kijuttatni, ha PL egy megfelelő exception-t eldobunk, amit elkapunk és lekezelünk. Itt is ezt fogjuk tenni.
Ahhoz hogy a hibaágakat is kezelni tudjuk, létre kell hozzunk egyedi Exception osztályokat, és hozzájuk tartozó response mapper-eket (Provider), amik az Exception eldobása estén megkapják a vezérlést, és az Exception alapján össze tudják állítani a választ. Ehhez három osztályt kell létrehozzunk:
# ErrorResponse osztály, egy egységesített struktúra, amit minden nem 200-as válaszban vár a kliens. (pl hibakódok, szöveges leírás)
# Saját Exception implementáció (WebServiceException), amibe minden olyan infónak szerepelnie kell, ami alapján az ErrorResponse osztály elkészíthető.
# Exception mapper provider osztály, ami megkapja a vezérlést ha WebServiceException dobódott, és a benne található információk alapján példányosítja a ErrorResponse osztályt, majd beleteszi a REST válaszba, amit a JAX-RS JSON formátumra fog hozni.
===Jax-RS provider===
