Babellenőrzés Jersey-ben

1. Áttekintés

Ebben az oktatóanyagban a Bean Validation-t vesszük szemügyre a Jersey nyílt forráskódú keretrendszer használatával.

Ahogy azt már korábbi cikkekben is láthattuk, Jersey egy nyílt forráskódú keretrendszer a RESTful Web Services fejlesztéséhez. A Jersey-vel és Spring-szel való API létrehozásának bevezetésében további részleteket kaphatunk Jersey-ről.

2. Babellenőrzés Jersey-ben

Az érvényesítés annak ellenőrzése, hogy egyes adatok megfelelnek-e egy vagy több előre meghatározott korlátozásnak. Természetesen ez a legtöbb alkalmazásban nagyon gyakori felhasználási eset.

A Java Bean Validation keretrendszer (JSR-380) de facto szabványsá vált az ilyen műveletek Java-ban történő kezelésére. Összefoglalva a Java Bean validálás alapjait, kérjük, olvassa el előző oktatóanyagunkat.

Jersey tartalmaz egy kiterjesztési modult a babellenőrzés támogatására. Ennek a képességnek az alkalmazásunkban való használatához először konfigurálnunk kell. A következő szakaszban megnézzük, hogyan konfigurálhatjuk az alkalmazásunkat.

3. Az alkalmazás beállítása

Most építsünk az egyszerű Fruit API példára, a kiváló Jersey MVC Support cikkből.

3.1. Maven-függőségek

Először tegyük hozzá a babellenőrzés függőségét pom.xml:

 org.glassfish.jersey.ext jersey-bab-validálás 2.27 

A legújabb verziót a Maven Central-tól kaphatjuk meg.

3.2. A szerver konfigurálása

Jersey-ben általában az egyéni erőforrás-konfigurációs osztályunkban regisztráljuk a használni kívánt kiterjesztési funkciót.

A babérvényesítés kiterjesztéséhez azonban nincs szükség erre a regisztrációra. Szerencsére ez egyike azon kevés kiterjesztéseknek, amelyeket a Jersey keretrendszer automatikusan regisztrál.

Végül, hogy érvényesítési hibákat küldjön az ügyfélnek hozzáadunk egy szerver tulajdonságot az egyéni erőforrás-konfigurációnkhoz:

public ViewApplicationConfig () {csomagok ("com.baeldung.jersey.server"); tulajdonság (ServerProperties.BV_SEND_ERROR_IN_RESPONSE, true); } 

4. A JAX-RS erőforrás-módszerek ellenőrzése

Ebben a szakaszban a bemeneti paraméterek érvényesítésének két különböző módját ismertetjük megkötés-jelölésekkel:

  • Beépített Bean Validation API korlátozások használata
  • Egyéni megszorítás és érvényesítő létrehozása

4.1. Beépített kényszerjegyzetek használata

Kezdjük azzal, hogy megvizsgáljuk a beépített kényszerjegyzeteket:

@POST @Path ("/ create") @Cumsumes (MediaType.APPLICATION_FORM_URLENCODED) public void createFruit (@NotNull (message = "A gyümölcs neve nem lehet null") @FormParam ("name") Karakterlánc neve, @NotNull (message = "A gyümölcs színe nem lehet nullás") @FormParam ("color") Húr színe) {Gyümölcs gyümölcs = új Gyümölcs (név, szín); SimpleStorageService.storeFruit (gyümölcs); } 

Ebben a példában létrehozunk egy újat Gyümölcs két űrlapparaméter használatával, név és szín. Használjuk a @Nem nulla annotáció, amely már része a Bean Validation API-nak.

Ez egyszerű, nem nulla korlátozást jelent az űrlapparamétereinkre. Abban az esetben, ha az egyik paraméter az nulla, az annotációban deklarált üzenet visszaküldésre kerül.

Természetes, hogy ezt egység teszt segítségével mutatjuk be:

@Test public void givenCreateFruit_whenFormContainsNullParam_thenResponseCodeIsBadRequest () {Form form = new Form (); form.param ("név", "alma"); form.param ("color", null); Válasz válasza = cél ("gyümölcs / létrehozás"). Kérelem (MediaType.APPLICATION_FORM_URLENCODED) .post (Entity.form (képernyő)); assertEquals ("A Http válasznak 400-nak kell lennie, 400, response.getStatus ()"; assertThat (response.readEntity (String.class), tartalmazzaString ("A gyümölcs színe nem lehet null")); } 

A fenti példában használjuk a JerseyTest támogató osztály a gyümölcsforrás teszteléséhez. POST kérést küldünk nullával szín és ellenőrizze, hogy a válasz tartalmazza-e a várt üzenetet.

A beépített érvényesítési korlátozások listájához tekintse meg a dokumentumokat.

4.2. Egyéni kényszerjegyzet meghatározása

Néha összetettebb korlátokat kell előírnunk. Ezt úgy tehetjük meg, hogy meghatározzuk saját egyéni feljegyzésünket.

Az egyszerű Fruit API példánk segítségével képzeljük el, hogy ellenőriznünk kell, hogy minden gyümölcsnek érvényes sorozatszáma van-e:

@PUT @Path ("/ update") @Cumsumes ("application / x-www-form-urlencoded") public void updateFruit (@SerialNumber @FormParam ("serial") Karaktersorozat) {// ...} 

Ebben a példában a paraméter sorozatszám meg kell felelnie a @Sorozatszám, amelyet legközelebb meghatározunk.

Először meghatározzuk a kényszer kommentárját:

@Retention (RetentionPolicy.RUNTIME) @Constraint (validatedBy = {SerialNumber.Validator.class}) public @interface SerialNumber {String message () alapértelmezett "A gyümölcs sorozatszáma érvénytelen"; Osztály [] csoportok () alapértelmezett {}; Class [] hasznos teher () alapértelmezett {}; } 

Ezután meghatározzuk a validátor osztályt SerialNumber.Validator:

public class Validator implementálja a ConstraintValidator {@Orride public void Initialize (SerialNumber serial) {} @Orride public boolean isValid (String serial, ConstraintValidatorContext constraintValidatorContext) {String serialNumRegex = "^ \ d {3} - \ d {3 \ d {4} $ "; return Pattern.matches (serialNumRegex, soros); }} 

A legfontosabb pont itt a Validator osztálynak végre kell hajtania ConstraintValidator hol T az érték típusa, amelyet érvényesíteni akarunk, esetünkben a Húr .

Végül ezt követően implementáljuk az egyedi érvényesítési logikánkat a érvényes módszer.

5. Erőforrás-hitelesítés

Ezenkívül a Bean Validation API lehetővé teszi az objektumok validálását is a @Érvényes annotáció.

A következő szakaszban az erőforrásosztályok érvényesítésének két különböző módját ismertetjük ennek a kommentárnak a használatával:

  • Először kérje az erőforrás érvényesítését
  • Másodszor: Válasz erőforrás érvényesítése

Kezdjük azzal, hogy hozzáadjuk a @Min annotáció a mi Gyümölcs tárgy:

@XmlRootElement nyilvános osztály Gyümölcs {@Min (érték = 10, üzenet = "A gyümölcs súlyának legalább 10-nek kell lennie") privát Egész súly; // ...} 

5.1. Erőforrás-ellenőrzés kérése

Mindenekelőtt engedélyezzük az érvényesítést a @Érvényes miénkben FruitResource osztály:

@POST @Path ("/ create") @Fogyaszt ("application / json") public void createFruit (@Valid Fruit fruit) {SimpleStorageService.storeFruit (gyümölcs); } 

A fenti példában ha megpróbálunk 10-nél kisebb súlyú gyümölcsöt létrehozni, akkor érvényesítési hibát kapunk.

5.2. Válasz erőforrás érvényesítése

Hasonlóképpen, a következő példában megnézzük, hogyan lehet érvényesíteni egy válaszerőforrást:

@GET @Valid @Produces ("application / json") @Path ("/ search / {name}") public Fruit findFruitByName (@PathParam ("name") String name) {return SimpleStorageService.findByName (name); }

Ne feledje, hogyan használjuk ugyanazt @Érvényes annotáció. De ezúttal az erőforrás módszer szintjén használjuk, hogy megbizonyosodhassunk a válasz érvényességéről.

6. Egyedi kivételkezelő

Ebben az utolsó részben röviden áttekintjük az egyedi kivételkezelő létrehozásának módját. Ez akkor hasznos, ha egyedi választ akarunk adni, ha megsértünk egy adott korlátozást.

Kezdjük azzal, hogy meghatározzuk a sajátunkat FruitExceptionMapper:

public class FruitExceptionMapper implementálja az ExceptionMapper {@Override public Response toResponse (ConstraintViolationException kivétel) {return Response.status (Response.Status.BAD_REQUEST) .entity (preparMessage (kivétel)) .type ("text / plain") .build (); } privát String PreparMessage (ConstraintViolationException kivétel) {StringBuilder üzenet = new StringBuilder (); for (ConstraintViolation cv: kivétel.getConstraintViolations ()) {message.append (cv.getPropertyPath () + "" + cv.getMessage () + "\ n"); } return message.toString (); }}

Először meghatározunk egy egyedi kivétel-hozzárendelési szolgáltatót. Ennek érdekében megvalósítjuk a ExceptionMapper interfész a ConstraintViolationException.

Ezért látni fogjuk, hogy amikor ezt a kivételt eldobják, a válaszol Az egyedi kivétel metódusa meghívásra kerül.

Emellett ebben az egyszerű példában az összes jogsértést átismételjük, és minden egyes tulajdonságot és üzenetet visszacsatolunk a válaszhoz.

Ezután az egyedi kivétel-leképező használatához regisztrálnunk kell a szolgáltatónkat:

@ Felülírás védett alkalmazáskonfiguráció () {ViewApplicationConfig config = new ViewApplicationConfig (); config.register (FruitExceptionMapper.class); return config; }

Végül hozzáadunk egy végpontot, amely érvénytelen értéket ad vissza Gyümölcs a kivételkezelő működés közbeni megjelenítése:

@GET @Produces (MediaType.TEXT_HTML) @Path ("/ kivétel") @Valid public Fruit kivétel () {Fruit fruit = new Fruit (); fruit.setName ("a"); gyümölcs.setColour ("b"); visszatérő gyümölcs; } 

7. Következtetés

Összefoglalva, ebben az oktatóanyagban feltártuk a Jersey Bean Validation API kiterjesztést.

Először azzal kezdtük, hogy bemutattuk, hogyan lehet a Bean Validation API-t használni Jersey-ben. Megvizsgáltuk egy webes alkalmazás példájának konfigurálását is.

Végül megvizsgáltuk az érvényesítés számos módját Jersey-szel, és hogyan írhatunk egyedi kivételkezelõt.

Mint mindig, a cikk teljes forráskódja elérhető a GitHubon.