Flow of Data in a Web App

[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