Requests and Responses

You've just completed your first successful Sinatra request. 0:00 Let's take a closer look at the request your browser sent and 0:03 how Sinatra responded. 0:06 When we ran our Sinatra app on our local machine, we accessed it by typing the URL 0:08 of HTTP localhost:4567/apple in our browser. 0:13 We'll start by breaking down that URL and see what its components mean. 0:20 The HTTP portion of the URL stands for Hypertext Transfer Protocol. 0:24 It's a set of rules that web browsers and 0:29 web servers use to communicate with each other. 0:31 Next is the address of the host, the computer running your web app [SOUND]. 0:35 In this case we use localhost which is a special name meaning this computer. 0:39 The browser will send a request from your computer to your computer. 0:44 After the host address, we have the port number to connecting. 0:48 It's possible for 0:52 several different network applications to be running on the same computer at once. 0:53 To prevent conflicts each of them listens on a different port or 0:57 communication channel [SOUND]. 1:01 Client programs need to connect to the correct port, so 1:02 [SOUND] that they talk to the correct app. 1:05 Most web servers that are intended for the public to connect to listen for 1:07 connections on port 80 and so that's where web browsers try to connect by default. 1:11 That's why you don't see port numbers specified at most URLs but 1:16 unless you explicitly tells Sinatra to run in production 1:20 that is specify that it's ready for the public to connect to. 1:24 It'll run on a different port which will show in the terminal log. 1:27 Be sure to specify that [SOUND] port in the URL, so 1:31 you can establish a connection. 1:33 The last part of the URL is the path of the resource you want to retrieve. 1:35 Web [SOUND] servers usually have many different resources they [SOUND] can serve 1:39 to browsers. 1:43 The path lets browser specify which resource they want. 1:44 Look at this more closely in a bit. 1:48 We've got our browsers developer tools open. 1:51 Let's visit the network monitoring tab, so 1:53 we can look at the communication between the browser and our Sinatra app. 1:55 Well hit return in the address bar and our browser will send the request. 2:00 This first line is the important part. 2:04 On the right, you see the version of HTTP the browser is communicating in and 2:07 here's the request itself GET /apple. 2:13 The first part of the request is the HTTP method. 2:17 HTTP support several different verbs or methods for requests. 2:20 They reflect the different operations you might need to carry out on the server, 2:26 GET retrieves the [SOUND] resource from the server, POST [SOUND] 2:30 adds a new resource to the server PUT [SOUND] modifies an existing resource. 2:34 And DELETE [SOUND] deletes a resource. 2:38 Our current request is retrieving a resource, so it uses the GET method. 2:40 We'll look at other methods later. 2:45 By the way HTTP method should not be confused with Ruby methods. 2:47 A Ruby method is a chunk of executable code but 2:51 an HTTP method just indicates the type of the request. 2:54 The second part of the request is the resource path [SOUND]. 2:58 A typical web server [SOUND] has many different resources that browses might 3:01 want to access. 3:06 The path specifies which resource a request is for, thinks that like a path to 3:07 a file in [SOUND] a directory, like you might use in your terminal. 3:11 In the early days of the web, that's exactly what most websites were, 3:15 [SOUND] a bunch of HTML files in different folders. 3:19 The path indicated which file to access. 3:22 Now that we're in the era of interactive web apps, 3:25 the path often points to a virtual [SOUND] resource like a database [SOUND] record. 3:27 But it still works the same way as far as the browser is concerned. 3:32 But for not using files how do we translate the request method and 3:36 path into an appropriate response from your web app. 3:40 The answer is Sinatra routes, 3:43 they route a particular request to app code that can handle that request. 3:45 The Sinatra library defines methods for 3:50 routing each HTTP request type including get, post, put and delete. 3:52 So here on our code where we call get/apple, it sets up a route for 3:58 get requests with a path of /apple. 4:02 The various methods for setting up Sinatra routes each take a block. 4:06 Sinatra will save that block and run at any time it gets a matching request. 4:09 So this block here will be running any time your app receives a get request for 4:14 the /apple path. 4:18 The last or only statement in a Ruby block body is its return value. 4:20 For the Sinatra get method, whatever value the block returns, 4:25 it'll be sent back to the browser in the response. 4:28 So this block returns the string, Here's a juicy apple. 4:31 And that string becomes the text that gets rendered in the browser. 4:35 We use the plain string before but 4:38 we can also include any HTML tags we want in the browser will render them. 4:40 So, we can make this text into a level one heading. 4:45 I'll add h1 tags here. 4:48 Now if we go back to our browser and hit refresh, 4:52 our changes won't actually show yet. 4:55 Unlike with Ruby on Rails changes we make to our code are not automatically loaded 4:58 in to our app. 5:02 We need to go to the terminal, pick Ctrl + c to stop the server. 5:04 And then run it again. 5:10 And now if we reload our page, our changes will show. 5:12 We've successfully set up our first Sinatra route. 5:17 But an app that can only take requests for one path and 5:20 give one response isn't too useful. 5:23 Next, we'll look at setting up multiple routes in the same app. 5:26 By the way, 5:29 you got just a brief glimpse of the web browsers developer tools in this video. 5:29 Most browsers have them and they're really useful for 5:34 inspecting the requests your browser sends and the HTML it gets back. 5:36 If you'd like more info on developer tools check the teacher's notes. 5:40