streamalism.org

1. Oversigt

I denne vejledning skal vi se på Bean Validation ved hjælp af open source framework Jersey.

Som vi allerede har set i tidligere artikler, Jersey er en open source-ramme til udvikling af RESTful Web Services. Vi kan få flere detaljer om Jersey i vores introduktion til, hvordan man opretter en API med Jersey og Spring.

2. Validering af bønner i Jersey

Validering er processen med at kontrollere, at nogle data overholder en eller flere foruddefinerede begrænsninger. Det er selvfølgelig en meget almindelig brugssag i de fleste applikationer.

Java Bean Validation Framework (JSR-380) er blevet de facto-standarden til håndtering af denne type operationer i Java. For at opsummere det grundlæggende i Java Bean Validation henvises til vores tidligere tutorial.

Jersey indeholder et udvidelsesmodul til understøttelse af bønnevalidering. For at bruge denne mulighed i vores applikation skal vi først konfigurere den. I det næste afsnit vil vi se, hvordan vi konfigurerer vores applikation.

3. Opsætning af applikation

Lad os nu bygge videre på det enkle Fruit API-eksempel fra den fremragende Jersey MVC Support-artikel.

3.1. Maven afhængigheder

Lad os først og fremmest tilføje afhængigheden af ​​bønnevalidering til vores pom.xml:

 org.glassfish.jersey.ext validering af jersey-bønne 2.27 

Vi kan få den nyeste version fra Maven Central.

3.2. Konfiguration af serveren

I Jersey registrerer vi normalt den udvidelsesfunktion, vi vil bruge i vores tilpassede ressourcekonfigurationsklasse.

For forlængelsen af ​​validering af bønner er det imidlertid ikke nødvendigt at foretage denne registrering. Heldigvis er dette en af ​​de få udvidelser, som Jersey-rammen registrerer automatisk.

Endelig at sende valideringsfejl til klienten Vi tilføjer en serveregenskab til vores en tilpasset ressourcekonfiguration:

offentlig ViewApplicationConfig () {pakker ("com.baeldung.jersey.server"); egenskab (ServerProperties.BV_SEND_ERROR_IN_RESPONSE, true); } 

4. Validering af JAX-RS ressourcemetoder

I dette afsnit forklarer vi to forskellige måder at validere inputparametre ved hjælp af begrænsningsanmærkninger:

• Brug af indbyggede Bean Validation API-begrænsninger
• Oprettelse af en brugerdefineret begrænsning og validator

4.1. Brug af indbyggede begrænsningsanmærkninger

Lad os starte med at se på indbyggede begrænsningsanmærkninger:

@POST @Path ("/ create") @Consumes (MediaType.APPLICATION_FORM_URLENCODED) public void createFruit (@NotNull (message = "Fruit name must not be null") @FormParam ("name") Navn på streng, @NotNull (message = "Frugtfarve må ikke være nul") @FormParam ("farve") Stringfarve) {Frugtfrugt = ny frugt (navn, farve); SimpleStorageService.storeFruit (frugt); } 

I dette eksempel opretter vi et nyt Frugt ved hjælp af to formparametre, navn og farve. Vi bruger @NotNull kommentar, som allerede er en del af til Bean Validation API.

Dette pålægger vores formularparametre en simpel ikke nul begrænsning. Hvis en af ​​parametrene er nul, vil den meddelelse, der er angivet i kommentaren, blive returneret.

Naturligvis demonstrerer vi dette med en enhedstest:

@Test offentlig ugyldighed givenCreateFruit_whenFormContainsNullParam_thenResponseCodeIsBadRequest () {Form form = new Form (); form.param ("navn", "æble"); form.param ("farve", null); Svarrespons = mål ("frugt / opret"). Anmodning (MediaType.APPLICATION_FORM_URLENCODED) .post (Entity.form (form)); assertEquals ("Http-svar skal være 400", 400, respons.getStatus ()); assertThat (response.readEntity (String.class), containString ("Frugtfarven må ikke være nul")); } 

I ovenstående eksempel vi bruger JerseyTest support klasse for at teste vores frugtressource. Vi sender en POST-anmodning med en null farve og kontroller, at svaret indeholder den forventede besked.

For at få en liste over indbyggede valideringsbegrænsninger, se på dokumenterne.

4.2. Definition af en brugerdefineret begrænsningskommentar

Nogle gange er vi nødt til at pålægge mere komplekse begrænsninger. Vi kan gøre dette ved at definere vores egen brugerdefinerede kommentar.

Lad os forestille os, at vi ved hjælp af vores enkle Fruit API-eksempel skal validere, at al frugt har et gyldigt serienummer:

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

I dette eksempel er parameteren seriel skal opfylde de begrænsninger, der er defineret af @Serienummer, som vi definerer derefter.

Vi definerer først begrænsningsannotationen:

@Retention (RetentionPolicy.RUNTIME) @Constraint (validatedBy = {SerialNumber.Validator.class}) public @interface SerialNumber {Strengmeddelelse () standard "Frugtserienummer er ikke gyldigt"; Klasse [] grupper () standard {}; Klasse [] nyttelast () standard {}; } 

Dernæst definerer vi validatorklassen Serienummer. Validator:

public class Validator implementerer ConstraintValidator {@Override public void initialize (SerialNumber serial) {} @Override public boolean isValid (String serial, ConstraintValidatorContext constraintValidatorContext) {String serialNumRegex = "^ \ d {3} - \ \ d {3} \ d {4} $ "; returner Pattern.matches (serialNumRegex, serial); }} 

Nøglepunktet her er Validator klasse skal implementere ConstraintValidator hvor T er den type værdi, vi vil validere, i vores tilfælde a Snor .

Endelig implementerer vi derefter vores brugerdefinerede valideringslogik i er gyldig metode.

5. Validering af ressourcer

Desuden giver Bean Validation API os også mulighed for at validere objekter ved hjælp af @Gyldig kommentar.

I det næste afsnit forklarer vi to forskellige måder at validere ressourceklasser ved hjælp af denne kommentar:

• Først, anmod om ressourcevalidering
• For det andet, Svar ressource validering

Lad os begynde med at tilføje @Min kommentar til vores Frugt objekt:

@XmlRootElement offentlig klasse Frugt {@Min (værdi = 10, meddelelse = "Frugtvægt skal være 10 eller større") privat Heltalsvægt; // ...} 

5.1. Anmod om validering af ressourcer

Først og fremmest vil vi aktivere validering ved hjælp af @Gyldig i vores Frugtressource klasse:

@POST @Path ("/ create") @Consumes ("application / json") public void createFruit (@Valid Fruit fruit) {SimpleStorageService.storeFruit (fruit); } 

I ovenstående eksempel hvis vi prøver at skabe en frugt med en vægt mindre end 10, får vi en valideringsfejl.

5.2. Validering af reaktionsressourcer

På samme måde vil vi i det næste eksempel se, hvordan vi validerer en svarressource:

@GET @Valid @Produces ("application / json") @Path ("/ search / {name}") public Fruit findFruitByName (@PathParam ("name") Navn på streng) {returner SimpleStorageService.findByName (navn); }

Bemærk, hvordan vi bruger det samme @Gyldig kommentar. Men denne gang bruger vi det på ressourcemetodeniveau for at være sikker på, at svaret er gyldigt.

6. Bruger af brugerdefineret undtagelse

I denne sidste del vil vi kort se på, hvordan man opretter en brugerdefineret undtagelsesbehandler. Dette er nyttigt, når vi ønsker at returnere et tilpasset svar, hvis vi overtræder en bestemt begrænsning.

Lad os begynde med at definere vores FruitExceptionMapper:

offentlig klasse FruitExceptionMapper implementerer ExceptionMapper {@Override public Response toResponse (ConstraintViolationException undtagelse) {return Response.status (Response.Status.BAD_REQUEST) .entity (prepareMessage (undtagelse)) .type ("text / plain") .build (); } private String prepareMessage (ConstraintViolationException undtagelse) {StringBuilder meddelelse = ny StringBuilder (); for (ConstraintViolation cv: exception.getConstraintViolations ()) {message.append (cv.getPropertyPath () + "" + cv.getMessage () + "\ n"); } returner besked.toString (); }}

Først og fremmest definerer vi en brugerdefineret kortlægningsudbyder. For at gøre dette implementerer vi ExceptionMapper interface ved hjælp af en ConstraintViolationException.

Derfor vil vi se, at når denne undtagelse kastes toResponse metode til vores brugerdefinerede undtagelseskorttilstedeværelsesinstans.

I dette enkle eksempel gentager vi alle overtrædelser og tilføjer hver ejendom og besked, der skal sendes tilbage i svaret.

For at kunne bruge vores brugerdefinerede undtagelseskort skal vi derefter registrere vores udbyder:

@ Override beskyttet Application configure () {ViewApplicationConfig config = new ViewApplicationConfig (); config.register (FruitExceptionMapper.class); returkonfiguration; }

Endelig tilføjer vi et slutpunkt for at returnere et ugyldigt Frugt for at vise undtagelsesbehandleren i aktion:

@GET @Produces (MediaType.TEXT_HTML) @Path ("/ exception") @Valid public Fruit undtagelse () {Fruit fruit = new Fruit (); fruit.setName ("a"); fruit.setColour ("b"); returnere frugt; } 

7. Konklusion

For at opsummere har vi i denne vejledning udforsket udvidelsen Jersey Bean Validation API.

Først startede vi med at introducere, hvordan Bean Validation API kan bruges i Jersey. Vi kiggede også på, hvordan man konfigurerer et eksempel på en webapplikation.

Endelig så vi på flere måder at foretage validering med Jersey og hvordan man skriver en brugerdefineret undtagelseshåndterer.

Som altid er artiklens fulde kildekode tilgængelig på GitHub.