streamalism.org

1. Oversikt

I denne veiledningen skal vi ta en titt på Bean Validation ved hjelp av open source framework Jersey.

Som vi allerede har sett i tidligere artikler, Jersey er et open source-rammeverk for utvikling av RESTful Web Services. Vi kan få mer informasjon om Jersey i vår introduksjon om hvordan du lager en API med Jersey og Spring.

2. Bønnevalidering i Jersey

Validering er prosessen med å verifisere at noen data overholder en eller flere forhåndsdefinerte begrensninger. Det er selvfølgelig en veldig vanlig brukssak i de fleste applikasjoner.

Java Bean Validation Framework (JSR-380) har blitt de facto-standarden for håndtering av denne typen operasjoner i Java. For å oppsummere det grunnleggende om Java Bean Validation, se vår forrige opplæring.

Jersey inneholder en utvidelsesmodul for å støtte Bean Validation. For å bruke denne muligheten i applikasjonen vår, må vi først konfigurere den. I neste avsnitt vil vi se hvordan vi konfigurerer applikasjonen vår.

3. Programoppsett

La oss nå bygge videre på det enkle Fruit API-eksemplet fra den fremragende artikkelen om Jersey MVC Support.

3.1. Maven avhengigheter

Først av alt, la oss legge til Bean Validation-avhengighet til vår pom.xml:

 org.glassfish.jersey.ext jersey-bean-validering 2.27 

Vi kan få den nyeste versjonen fra Maven Central.

3.2. Konfigurere serveren

I Jersey registrerer vi vanligvis utvidelsesfunksjonen vi vil bruke i vår tilpassede ressurskonfigurasjonsklasse.

For forlengelsen av bønnevalidering er det imidlertid ikke nødvendig å gjøre denne registreringen. Heldigvis er dette en av få utvidelser som Jersey-rammeverket registrerer automatisk.

Til slutt, for å sende valideringsfeil til klienten Vi legger til en serveregenskap i en tilpasset ressurskonfigurasjon:

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

4. Validering av JAX-RS ressursmetoder

I denne delen forklarer vi to forskjellige måter å validere inndataparametere ved å bruke begrensningsanmerkninger:

• Bruker innebygde Bean Validation API-begrensninger
• Opprette en tilpasset begrensning og validator

4.1. Bruke innebygde begrensningsanmerkninger

La oss starte med å se på innebygde begrensningsanmerkninger:

@POST @Path ("/ create") @Consumes (MediaType.APPLICATION_FORM_URLENCODED) public void createFruit (@NotNull (message = "Fruktnavn må ikke være null") @FormParam ("name") Strengnavn, @NotNull (message = "Fruktfarge må ikke være null") @FormParam ("farge") Strengfarge) {Fruktfrukt = ny frukt (navn, farge); SimpleStorageService.storeFruit (frukt); } 

I dette eksemplet lager vi et nytt Frukt ved hjelp av to skjemaparametere, Navn og farge. Vi bruker @Ikke null kommentar som allerede er en del av Bean Validation API.

Dette pålegger en enkel ikke null begrensning for skjemaparametrene våre. I tilfelle en av parametrene er null, vil meldingen deklarert i kommentaren bli returnert.

Naturligvis vil vi demonstrere dette med en enhetstest:

@Test offentlig ugyldig givenCreateFruit_whenFormContainsNullParam_thenResponseCodeIsBadRequest () {Form form = new Form (); form.param ("navn", "eple"); form.param ("farge", null); Svarrespons = mål ("frukt / opprett"). Forespørsel (MediaType.APPLICATION_FORM_URLENCODED) .post (Entity.form (form)); assertEquals ("Http Response should be 400", 400, response.getStatus ()); assertThat (response.readEntity (String.class), inneholderString ("Fruktfarge må ikke være null")); } 

I eksemplet ovenfor, vi bruker JerseyTest støtteklasse for å teste fruktressursen vår. Vi sender en POST-forespørsel med null farge og sjekk at svaret inneholder den forventede meldingen.

For en liste over innebygde valideringsbegrensninger, ta en titt på dokumentene.

4.2. Definere en tilpasset begrensningskommentar

Noen ganger må vi innføre mer komplekse begrensninger. Vi kan gjøre dette ved å definere vår egen tilpassede kommentar.

La oss forestille oss at vi må validere at all frukt har et gyldig serienummer ved å bruke vårt enkle Fruit API-eksempel:

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

I dette eksemplet er parameteren seriell må tilfredsstille begrensningene definert av @Serienummer, som vi definerer neste.

Vi definerer først begrensningsanmerkingen:

@Retention (RetentionPolicy.RUNTIME) @Constraint (validatedBy = {SerialNumber.Validator.class}) public @interface SerialNumber {Strengmelding () standard "Frukt serienummer er ikke gyldig"; Klasse [] grupper () standard {}; Klasse [] nyttelast () standard {}; } 

Deretter definerer vi validatorklassen SerialNumber. Validator:

offentlig klasse 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økkelpunktet her er Validator klasse må implementere ConstraintValidator hvor T er den typen verdi vi vil validere, i vårt tilfelle a String .

Til slutt implementerer vi vår tilpassede valideringslogikk i er gyldig metode.

5. Ressursvalidering

Videre lar Bean Validation API oss også validere objekter ved hjelp av @Gyldig kommentar.

I neste avsnitt forklarer vi to forskjellige måter å validere ressursklasser ved hjelp av denne kommentaren:

• Først, be om ressursvalidering
• For det andre, validering av svarressurs

La oss begynne med å legge til @Min kommentar til vår Frukt gjenstand:

@XmlRootElement offentlig klasse Frukt {@Min (verdi = 10, melding = "Fruktvekt må være 10 eller større") privat Heltall; // ...} 

5.1. Be om ressursvalidering

Først og fremst aktiverer vi validering ved hjelp av @Gyldig i vår FruitResource klasse:

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

I eksemplet ovenfor, hvis vi prøver å lage en frukt med en vekt mindre enn 10, får vi en valideringsfeil.

5.2. Svarresursvalidering

På samme måte ser vi i neste eksempel hvordan vi validerer en svarressurs:

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

Merk, hvordan vi bruker det samme @Gyldig kommentar. Men denne gangen bruker vi det på ressursmetodenivå for å være sikker på at svaret er gyldig.

6. Custom Exception Handler

I denne siste delen vil vi kort se på hvordan du lager en tilpasset unntaksbehandler. Dette er nyttig når vi ønsker å returnere et tilpasset svar hvis vi bryter en bestemt begrensning.

La oss begynne med å definere vår FruitExceptionMapper:

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

Først og fremst definerer vi en tilpasset leverandør av kartleggings unntak. For å gjøre dette implementerer vi ExceptionMapper grensesnitt ved hjelp av en ConstraintViolationException.

Derfor vil vi se at når dette unntaket blir kastet toResponse metoden for vår tilpassede unntakskartleggerinstans vil bli påkalt.

I dette enkle eksemplet gjentar vi også alle bruddene og legger til hver eiendom og melding som skal sendes tilbake i svaret.

Deretter må vi registrere leverandøren vår for å kunne bruke vår tilpassede unntakskartlegger:

@ Override-beskyttet applikasjonskonfigurasjon () {ViewApplicationConfig config = ny ViewApplicationConfig (); config.register (FruitExceptionMapper.class); returkonfigurasjon; }

Til slutt legger vi til et sluttpunkt for å returnere et ugyldig Frukt for å vise unntakshandleren i aksjon:

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

7. Konklusjon

For å oppsummere har vi i denne opplæringen utforsket Jersey Bean Validation API-utvidelsen.

Først begynte vi med å introdusere hvordan Bean Validation API kan brukes i Jersey. Vi så også på hvordan du konfigurerer et eksempel på en webapplikasjon.

Til slutt så vi på flere måter å utføre validering med Jersey og hvordan du skriver en tilpasset unntaksbehandler.

Som alltid er hele kildekoden til artikkelen tilgjengelig på GitHub.