Preview
Video Player
00:00
00:00
Requests and Responses
5:44You've just completed your first successful Sinatra request. Let's take a closer look at the request your browser sent, and how Sinatra responded.
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