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