You've just completed your first successful Sinatra request.

Let's take a closer look at the request your browser sent and

how Sinatra responded.

When we ran our Sinatra app on our local machine, we accessed it by typing the URL

of HTTP localhost:4567/apple in our browser.

We'll start by breaking down that URL and see what its components mean.

The HTTP portion of the URL stands for Hypertext Transfer Protocol.

It's a set of rules that web browsers and

web servers use to communicate with each other.

Next is the address of the host, the computer running your web app [SOUND].

In this case we use localhost which is a special name meaning this computer.

The browser will send a request from your computer to your computer.

After the host address, we have the port number to connecting.

It's possible for

several different network applications to be running on the same computer at once.

To prevent conflicts each of them listens on a different port or

communication channel [SOUND].

Client programs need to connect to the correct port, so

[SOUND] that they talk to the correct app.

Most web servers that are intended for the public to connect to listen for

connections on port 80 and so that's where web browsers try to connect by default.

That's why you don't see port numbers specified at most URLs but

unless you explicitly tells Sinatra to run in production

that is specify that it's ready for the public to connect to.

It'll run on a different port which will show in the terminal log.

Be sure to specify that [SOUND] port in the URL, so

you can establish a connection.

The last part of the URL is the path of the resource you want to retrieve.

Web [SOUND] servers usually have many different resources they [SOUND] can serve

to browsers.

The path lets browser specify which resource they want.

Look at this more closely in a bit.

We've got our browsers developer tools open.

Let's visit the network monitoring tab, so

we can look at the communication between the browser and our Sinatra app.

Well hit return in the address bar and our browser will send the request.

This first line is the important part.

On the right, you see the version of HTTP the browser is communicating in and

here's the request itself GET /apple.

The first part of the request is the HTTP method.

HTTP support several different verbs or methods for requests.

They reflect the different operations you might need to carry out on the server,

GET retrieves the [SOUND] resource from the server, POST [SOUND]

adds a new resource to the server PUT [SOUND] modifies an existing resource.

And DELETE [SOUND] deletes a resource.

Our current request is retrieving a resource, so it uses the GET method.

We'll look at other methods later.

By the way HTTP method should not be confused with Ruby methods.

A Ruby method is a chunk of executable code but

an HTTP method just indicates the type of the request.

The second part of the request is the resource path [SOUND].

A typical web server [SOUND] has many different resources that browses might

want to access.

The path specifies which resource a request is for, thinks that like a path to

a file in [SOUND] a directory, like you might use in your terminal.

In the early days of the web, that's exactly what most websites were,

[SOUND] a bunch of HTML files in different folders.

The path indicated which file to access.

Now that we're in the era of interactive web apps,

the path often points to a virtual [SOUND] resource like a database [SOUND] record.

But it still works the same way as far as the browser is concerned.

But for not using files how do we translate the request method and

path into an appropriate response from your web app.

The answer is Sinatra routes,

they route a particular request to app code that can handle that request.

The Sinatra library defines methods for

routing each HTTP request type including get, post, put and delete.

So here on our code where we call get/apple, it sets up a route for

get requests with a path of /apple.

The various methods for setting up Sinatra routes each take a block.

Sinatra will save that block and run at any time it gets a matching request.

So this block here will be running any time your app receives a get request for

the /apple path.

The last or only statement in a Ruby block body is its return value.

For the Sinatra get method, whatever value the block returns,

it'll be sent back to the browser in the response.

So this block returns the string, Here's a juicy apple.

And that string becomes the text that gets rendered in the browser.

We use the plain string before but

we can also include any HTML tags we want in the browser will render them.

So, we can make this text into a level one heading.

I'll add h1 tags here.

Now if we go back to our browser and hit refresh,

our changes won't actually show yet.

Unlike with Ruby on Rails changes we make to our code are not automatically loaded

in to our app.

We need to go to the terminal, pick Ctrl + c to stop the server.

And then run it again.

And now if we reload our page, our changes will show.

We've successfully set up our first Sinatra route.

But an app that can only take requests for one path and

give one response isn't too useful.

Next, we'll look at setting up multiple routes in the same app.

By the way,

you got just a brief glimpse of the web browsers developer tools in this video.

Most browsers have them and they're really useful for

inspecting the requests your browser sends and the HTML it gets back.

If you'd like more info on developer tools check the teacher's notes.