[MUSIC]

Welcome back.

At this point, you've seen our three tiered designed to get flip with the web,

service and DAO layers.

The remainder of our work here is focused on user interactions with our data,

made available by our HTML user interface.

In most software, we don't want to require users to interact with their DB directly

and even more, our users would probably never want to do so anyway.

So we build an intuitive UI for them.

If you think about, it any application that involves user interaction

can be considered a user interface for its underlying data.

And this is especially the case with web applications that expose a UI with HTML.

These applications visualize the data in meaningful and engaging ways

offering opportunities to interact with and often change the underlying data.

Now, in order to be able to cope with those opportunities for

interaction we have to be well versed, not only in the coding of the UI.

And in the processing of user actions once they hit our server but

also in the flow of data between the client and our server.

Let's take a look at the flow of data between a web client such as a browser and

a web server in two scenarios.

The first scenario is one in which a user has clicked on a read-only link or

one that doesn't result in a change to the underlying data of an application,

like clicking on a category to view all the GIFs in that category.

In general, the request response cycle is pretty brief.

A user clicks on a category link, which has a certain URL associated with it.

The browser captures this click, crafts an HTTP request using the URL and

sends that request to the host and URI extracted from the URL.

Our application, residing on the server at the specified host captures the URI

from the request calls a specific controller method, renders a view and

sends the rendered HTML as the HTTP response.

The user then sees this response, which in this case might be a list of

all the gifts that are part of the category that they clicked on.

In summary, there is one HTTP request and one HTTP response.

The next scenario is when a user presses the submit button of an HTML form.

For example, this could be a user entering a new category name,

then clicking a submit button to add the category.

The browser captures this click and because it's HTML for

method is coded as post, the browser crafts an HTTP POST Request.

Using the form's action attribute to generate a host and URI and

using the form's input elements that the user has provided values for,

to stick in the body or payload of the HTTP request.

The browser then sends the request.

Again, our application,

residing on the server at the specified in the HTTP request, receives the request

invoking one of our controller methods that has been annotated to handle the URL.

Here's where we depart a bit from the first scenario.

Let's assume that our controller successfully adds the category

the user requested to add instead of returning a typical HTML response.

What typically happens is that an application would return to the browser

a response.

With a 302 response code recall from HTTP

basics that 300 level codes are used for giving redirection instructions.

So, in the headers that this HTTP response is a location header

containing the URL for whatever we want to redirect, maybe the categories page.

The browser, upon receiving a response, reads the location header and

immediately crafts an HTTP request.

This time a Get Request, as opposed to the previous post request,

uses the host from the UI that is found in the location headers URL.

The browser sends this request, remember, for

the categories page, to the server using the host name.

At this point, the server receives this Get Request just like any other.

It invokes the associated controller method, a view is rendered to HTML and

the HTML is returned in the HTTP Response which the browser receives and

renders for the user.

In summary, a post request response cycle usually involves one HTTP POST Request,

a redirect HTTP Response to the browser.

Another HTTP Request, this time a Get Request and

finally an HTTP Response with a final HTML primed for another interaction.

This is called the post/redirect/get pattern and is used

by countless web applications, regardless of the language they're written in.

It's important to note that even though an extra request response cycle is used with

post actions, the user is none the wiser.

He or she sees only the form, clicks the submit button and

sees the result of the final Get Request that was made after the redirect.

The redirect itself is usually not visible.

Now that you have an idea about how the flow of data will work for both Get and

Post requests, we are ready to start putting together the HTML and

Java code necessary for handling those requests