Håndtering af URL-kodede formulardata i foråret REST

REST Top

Jeg har lige annonceret det nye Lær foråret kursus med fokus på det grundlæggende i Spring 5 og Spring Boot 2:

>> KONTROLLER KURSEN

1. Oversigt

For en slutbruger er processen med formularindsendelse praktisk og til en vis grad svarende til bare indtastning af data og klik på en send-knap. Fra et teknisk perspektiv kræver det imidlertid en kodningsmekanisme for pålideligt at sende og modtage disse data fra klientsiden til serversiden til back-end-behandling.

For omfanget af denne vejledning skal vi fokus på at skabe en formular, der sender dens data som application / x-www-form-urlencoded indholdstype i en Spring-webapplikation.

2. Formular datakodning

Den mest anvendte HTTP-metode til formularindsendelser er POST. For idempotente formularindsendelser kan vi dog også bruge HTTP GET-metoden. Og måden at specificere metoden er gennem formens metodeattribut.

For formularer, der bruger GET-metoden, sendes hele formulardata som en del af forespørgselsstrengen. Men hvis vi bruger POST-metoden, sendes dens data som en del af HTTP-anmodningens hoveddel.

Desuden kan vi i sidstnævnte tilfælde også angiv kodning af data med formularerne enctype attribut, som kan tage to værdier, nemlig application / x-www-form-urlencoded og multipart / form-data.

2.1. Medietype application / x-www-form-urlencoded

HTML formularer har en standardværdi på application / x-www-form-urlencoded til enctype attribut da dette tager sig af de grundlæggende anvendelsestilfælde, hvor data er udelukkende tekst. Ikke desto mindre, hvis vores brugssag indebærer understøttelse af fildata, bliver vi nødt til at tilsidesætte dem med en værdi på multipart / form-data.

I det væsentlige sender det formulardata som nøgleværdipar adskilt af et tegn (&). Desuden er den respektive nøgle og værdi adskilt med ligetegnet (=). Yderligere er alle reserverede og ikke-alfanumeriske tegn kodet ved hjælp af procentkodning.

3. Formularafsendelse i browser

Nu hvor vi har vores grundlæggende dækning, lad os gå videre og se, hvordan vi kan håndtere URL-kodede formulardata til et simpelt brugstilfælde ved feedbackindsendelse i en forårsweb-app.

3.1. Domæne Model

For vores feedbackformular er vi nødt til at registrere afsenderens e-mail-id sammen med kommentaren. Så lad os oprette vores domænemodel i en Feedback klasse:

offentlig klassefeedback {private String emailId; privat strengkommentar; }

3.2. Opret formular

For at bruge en simpel HTML-skabelon til at oprette vores dynamiske webformular skal vi konfigurere Thymeleaf i vores projekt. Efter dette er vi klar til at tilføje en FÅ slutpunkt / feedback der vil tjene feedback visning for formularen:

@GetMapping (sti = "/ feedback") offentlig streng getFeedbackForm (modelmodel) {Feedback feedback = ny feedback (); model.addAttribute ("feedback", feedback); returner "feedback"; }

Bemærk, at vi bruger feedback som en modelattribut til at fange brugerindgangen. Lad os derefter oprettefeedback se i feedback.html skabelon:

Selvfølgelig behøver vi ikke eksplicit at specificere enctype attribut, da det vælger standardværdien af application / x-www-form-urlencoded.

3.3. PRG Flow

Da vi accepterer brugerinput via browserens feedbackformular, skal vi implementer POST / REDIRECT / GET (PRG) -sendingsarbejdsprocessen for at undgå duplikerede indsendelser.

Lad os først implementere POST-slutpunktet / web / feedback der fungerer som handlingshåndterer for feedbackformularen:

@PostMapping (sti = "/ web / feedback", forbruger = {MediaType.APPLICATION_FORM_URLENCODED_VALUE}) offentlig strenghåndtagBrowserSubmissions (Feedbackfeedback) kaster undtagelse {// Gem feedbackdata returner "omdirigering: / feedback / succes"; }

Dernæst kan vi implementere omdirigeringsendepunktet / feedback / succes der tjener en GET-anmodning:

@GetMapping ("/ feedback / success") offentlig ResponseEntity getSuccess () {returner ny ResponseEntity ("Tak fordi du sendte feedback.", HttpStatus.OK); }

Lad os besøge for at validere funktionaliteten af ​​formularindsendelsesarbejdsprocessen i en browser localhost: 8080 / feedback:

Endelig kan vi også inspicere, at formulardata sendes i URL-kodet form:

emailId = abc% 40eksempel.com & kommentar = Prøve + feedback

4. Anmodninger, der ikke er browser

Til tider har vi muligvis ikke en browserbaseret HTTP-klient. I stedet kan vores klient være et værktøj som cURL eller Postman. I et sådant tilfælde har vi ikke brug for HTML-webformularen. I stedet kan vi implementere en / feedback slutpunkt, der tjener POST-anmodningen:

@PostMapping (sti = "/ feedback", forbruger = {MediaType.APPLICATION_FORM_URLENCODED_VALUE}) offentlig ResponseEntity-håndtagNonBrowserSubmissions (@RequestBody Feedback feedback) kaster undtagelse {// Gem feedbackdata returner ResponseEntity ("Tak for indsendelse af feedback", HttPStus ); }

I mangel af HTML-formular i vores datastrøm behøver vi ikke nødvendigvis at implementere PRG-mønsteret. Imidlertid, vi skal specificere, at ressourcen accepterer APPLICATION_FORM_URLENCODED_VALUE medietype.

Endelig kan vi teste det med en cURL-anmodning:

krølle -X POST \ // localhost: 8080 / feedback \ -H 'Content-Type: application / x-www-form-urlencoded' \ -d 'emailId = abc% 40example.com & comment = Sample% 20Feedback'

4.1. FormHttpMessageConverter Grundlæggende

En HTTP-anmodning, der sendes application / x-www-form-urlencoded data skal specificere dette i Indholdstype header. Internt bruger Spring den FormHttpMessageConverter klasse for at læse disse data og binde dem med metodeparameteren.

I tilfælde, hvor vores metodeparameter er af en type MultiValueMap, kan vi bruge enten @RequestParam eller @RequestBody kommentar for at binde den korrekt med selve HTTP-anmodningen. Det skyldes, at Servlet API kombinerer forespørgselsparametre og formulardata til et enkelt kort kaldet parametre, og det inkluderer automatisk parsing af anmodningsorganet:

@PostMapping (sti = "/ feedback", forbruger = {MediaType.APPLICATION_FORM_URLENCODED_VALUE}) offentlig ResponseEntity-håndtagNonBrowserSubmissions (@RequestParam MultiValueMap paramMap) kaster Undtagelse {// Gem feedbackdata returner ResponseEntity ("Tak for Http. Feedback) ); }

Imidlertid, for en metode parameter af en anden type end MultiValueMap, som vores Feedback domæne objekt, må vi kun bruge @RequestBody kommentar.

5. Konklusion

I denne vejledning lærte vi kort om kodning af formulardata i webformularer. Vi undersøgte også, hvordan vi håndterer URL-kodede data til browser- og ikke-browser-HTTP-anmodninger ved at implementere en feedbackformular i en Spring Boot-webapp.

Som altid er den komplette kildekode til vejledningen tilgængelig på GitHub.

REST bunden

Jeg har lige annonceret det nye Lær foråret kursus med fokus på det grundlæggende i Spring 5 og Spring Boot 2:

>> KONTROLLER KURSEN

$config[zx-auto] not found$config[zx-overlay] not found