Full Web Apps with FastAPI Transcripts
Chapter: Users and HTML forms
Lecture: GET/POST/Redirect pattern in FastAPI
Login or
purchase this course
to watch this video and the rest of the course contents.
0:00
Before we go about writing our login form or a register form or any HTML form. Let's talk about a pattern that is super common on web applications,
0:11
and we're gonna use it here in FastAPI. It's the GET > POST > Redirect pattern,
0:15
and for sites that are designed well and you've had good experiences with, I'm sure they're using this pattern over and over again.
0:22
Let's talk about it. So we've got our server, our server stores it's data in a database,
0:27
and we've got you sitting on your laptop working with your web browser. Let's suppose you want to go to the site that's hosted on the server,
0:34
you want to create an account, you want to register for the site. How do you do that? You visit a page and it shows you an empty
0:41
HTML form. The way you do that is you do an HTTP GET request against
0:46
/account/register and an empty form comes and says, great you'd like to register? what's your name? what's your email? what's your password?
0:54
They always make you confirm your password, or sometimes even your email both of those are annoying to me. I don't really like it that they do it.
1:00
But, you know, that's how these things go, right? You have one of these, these types of forms that gets shown here.
1:05
Then, you edit it locally and you want to say I filled it out, save it on the server. What you're going to do is an HTTP POST, often
1:14
back to the exact same URL. That's gonna take the form, post it back to the server. Server's gonna look at that and say,
1:20
well, now you're submitting the form instead of wanting to just see it because it's a POST and not a GET and it has data, it's not empty.
1:28
If it's good, you get to carry on. If there's a mistake, the form, that POST will just reload the page and say there's some kind of mistake, you know,
1:35
like that account already exists, you can't use that email address or whatever. But let's assume that it worked out well.
1:41
What it's gonna do is save some data to the database, and then it's going to send a 302 redirect like you submitted the form
1:47
but now we want you to go over to /account. The last thing you want is to just stay on that registration page and say OK, now go find somewhere to go.
1:56
No, you take them where you want to go. So in this case, they've created an account, let's take them to their account, or maybe to their onboarding
2:03
for whatever this website is, they'll GET > POST > Redirect. Super, super common pattern on many, many websites.
2:10
And that's how we're gonna construct, how we're gonna put together our user login as
2:15
well as our user registration. So we're gonna have one view that handles the GET
2:19
to register, the one that just shows the form. The other one is gonna handle the POST which actually validates the data and creates the accounts.
2:26
Now, if you look around, you'll see that this is not a pattern that I just made up.
2:30
It's also something that gets used in a lot of places. Over on Wikipedia, they call it the Post/Redirect/Get To me, and I don't think so,
2:37
I think of it as GET > POST > Redirect. You start with an empty form, you submit it, you go somewhere else
2:43
when you're done. Here, it kind of starts like halfway through that process. Like I guess you're posting something you magically acquired,
2:48
right? So anyway, they call it Post/Redirect/Get. You'll see it under several names, choose the one that you think that makes the most sense.
2:54
So common pattern. Anytime you're working with server side HTML forms, which we are, and we're gonna do that for our account management.