This course will be retired on January 8, 2022.
Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
In this video, we discuss two scenarios for the HTTP request/response cycle. In the first, a GET request is made to our application, and our application responds with content. In the second, a POST request is made, our application takes actions and responds with a redirect (location header), which results in a subsequent GET request to our app, where our app then responds with content. This scenario is called the POST/redirect/GET pattern.
[MUSIC]
0:00
Welcome back.
0:04
At this point, you've seen our three
tiered designed to get flip with the web,
0:05
service and DAO layers.
0:10
The remainder of our work here is focused
on user interactions with our data,
0:12
made available by our HTML user interface.
0:16
In most software, we don't want to require
users to interact with their DB directly
0:20
and even more, our users would
probably never want to do so anyway.
0:25
So we build an intuitive UI for them.
0:29
If you think about, it any application
that involves user interaction
0:33
can be considered a user interface for
its underlying data.
0:37
And this is especially the case with web
applications that expose a UI with HTML.
0:42
These applications visualize the data
in meaningful and engaging ways
0:48
offering opportunities to interact with
and often change the underlying data.
0:52
Now, in order to be able to cope
with those opportunities for
0:57
interaction we have to be well versed,
not only in the coding of the UI.
1:00
And in the processing of user
actions once they hit our server but
1:04
also in the flow of data between
the client and our server.
1:08
Let's take a look at the flow of data
between a web client such as a browser and
1:13
a web server in two scenarios.
1:18
The first scenario is one in which a user
has clicked on a read-only link or
1:21
one that doesn't result in a change to
the underlying data of an application,
1:26
like clicking on a category to view
all the GIFs in that category.
1:30
In general, the request
response cycle is pretty brief.
1:34
A user clicks on a category link, which
has a certain URL associated with it.
1:38
The browser captures this click,
crafts an HTTP request using the URL and
1:42
sends that request to the host and
URI extracted from the URL.
1:48
Our application, residing on the server
at the specified host captures the URI
1:53
from the request calls a specific
controller method, renders a view and
1:58
sends the rendered HTML
as the HTTP response.
2:04
The user then sees this response,
which in this case might be a list of
2:08
all the gifts that are part of
the category that they clicked on.
2:13
In summary, there is one HTTP request and
one HTTP response.
2:17
The next scenario is when a user presses
the submit button of an HTML form.
2:23
For example, this could be a user
entering a new category name,
2:29
then clicking a submit
button to add the category.
2:32
The browser captures this click and
because it's HTML for
2:36
method is coded as post,
the browser crafts an HTTP POST Request.
2:40
Using the form's action attribute
to generate a host and URI and
2:45
using the form's input elements that
the user has provided values for,
2:50
to stick in the body or
payload of the HTTP request.
2:54
The browser then sends the request.
2:59
Again, our application,
3:02
residing on the server at the specified
in the HTTP request, receives the request
3:04
invoking one of our controller methods
that has been annotated to handle the URL.
3:09
Here's where we depart a bit
from the first scenario.
3:15
Let's assume that our controller
successfully adds the category
3:18
the user requested to add instead of
returning a typical HTML response.
3:22
What typically happens is that
an application would return to the browser
3:27
a response.
3:30
With a 302 response code recall from HTTP
3:31
basics that 300 level codes are used for
giving redirection instructions.
3:36
So, in the headers that this HTTP
response is a location header
3:41
containing the URL for whatever we want
to redirect, maybe the categories page.
3:46
The browser, upon receiving a response,
reads the location header and
3:53
immediately crafts an HTTP request.
3:57
This time a Get Request,
as opposed to the previous post request,
4:00
uses the host from the UI that is
found in the location headers URL.
4:04
The browser sends this request,
remember, for
4:10
the categories page,
to the server using the host name.
4:13
At this point, the server receives
this Get Request just like any other.
4:17
It invokes the associated controller
method, a view is rendered to HTML and
4:22
the HTML is returned in the HTTP Response
which the browser receives and
4:27
renders for the user.
4:32
In summary, a post request response cycle
usually involves one HTTP POST Request,
4:35
a redirect HTTP Response to the browser.
4:40
Another HTTP Request,
this time a Get Request and
4:44
finally an HTTP Response with a final
HTML primed for another interaction.
4:47
This is called the post/redirect/get
pattern and is used
4:54
by countless web applications, regardless
of the language they're written in.
4:58
It's important to note that even though an
extra request response cycle is used with
5:02
post actions, the user is none the wiser.
5:06
He or she sees only the form,
clicks the submit button and
5:10
sees the result of the final Get Request
that was made after the redirect.
5:13
The redirect itself is
usually not visible.
5:18
Now that you have an idea about how the
flow of data will work for both Get and
5:21
Post requests, we are ready to
start putting together the HTML and
5:25
Java code necessary for
handling those requests
5:29
You need to sign up for Treehouse in order to download course files.
Sign up