Prerequisite

None.

Objective

You will learn the basics of HTTP and process HTTP requests using a simple web application.

The internet is powered by requests...

The basic model of the internet is based on a request. Almost everything on the internet is exchanged using a few standard HTTP methods:

GET

As the name suggests, get is an action where you retrieve information from a location in the internet. You have been using get for as long as you have started surfing the internet. Some examples:

• Every time you access a website by its web link, your browser is making a get request to get the website contents and displaying on your device.
• Every time you load your Facebook app, under the hood it makes a get request to fetch the news feed contents.

Get also allows you to get slightly different versions of a website by using query parameters. As an example, if you put https://www.bing.com/search?q=best+sushi into your browser task bar, Bing will automatically find results for the keyword best sushi. (more on this in exercises below.)

Get is typically only used as a way to fetch and not change a resource. For that you need to use POST.

POST

Post is another very common action that is used to make changes to a resource. Without you knowing, you have also been using post behind the scenes for:

• When creating a user account on a new website.
• When posting images on Instagram, under the hood it packages your image and text together and makes a post request to Instagram's server for processing.

Post requests are also special in that they are securely transmitted in the form of form parameters. When using in conjunction with secure HTTPS, it keeps the contents encrypted between the origin (your browser or app) and the destination.

With every request, there must be a response...

No matter the type of request, whether GET or POST, the protocol requires there be a response. You may be familiar with the dreaded 404 Not Found when you try to access something that is missing online. Apart from 404 there are many more codes; some of the common ones are

• 200 for success.
• 302 for redirection to another link.
• 400 bad request. This indicates a problem on the request. There was information sent to the destination that the destination did not prepare for.
• 500 server error. This indicates a problem on the destination. Perhaps the server crashed when processing a request midway.

Status codes are usually accompanied by a response body. Example, for browsers you almost never see 200 ever printed on the page because a successful 200 almost always accompanies the page content you requested for.

In the most severe of cases if there is no response, then it becomes a timeout error. You may have encountered this if you tried to shop on a very busy E-commerce site when the entire site ground to a halt.

Wait, then who processes all these requests?

This is where web applications come in!

Web applications open themselves to receiving requests from the internet. Every time a request is received, the application will:

• Figure what type of request is it (get, post, etc.).
• Which route it goes to.
• What are the url or form parameters that accompanied the request.

The application takes these information and does the processing accordingly and then determines the correct type of response and response body to return back to the origin.

And then the cycle continues...

As you move from page to page, and swipe along your app, you are really just making requests upon requests to get the content you need.

Of course the internet is made up of more complicated protocols for other media like:

• WebSockets for real-time signalling
• WebRTC for voice and video transmission
• FTP for large file transfers
• SMTP for emails
• and many more...

But for starters, knowing just how to make and respond to HTTP requests can get you started making really interactive websites!

Additional resources / reading

This module will require a lot of self reading. However, if you are stuck anywhere, feel free to ping me! Google and YouTube will be your best friend.

• The Http and the Web | Http Explained | Request-Response Cycle - https://www.youtube.com/watch?v=eesqK59rhGA
• How does the INTERNET work? - https://www.youtube.com/watch?v=x3c1ih2NJEg. This is optional. Only if you are interested in how exactly a request is routed to a site.
• Inspect Network Activity - Chrome DevTools 101 - https://www.youtube.com/watch?v=e1gAyQuIFQo. The first 3-4 minutes is a great video on how to navigate and make sense of the network tab. The later part is more complicated.

Exercises to try on your own

Observe your own browser traffic

Let's look under the hood of the web browser!

• Fire up Google Chrome
• Go to Google. Open the web inspector (either right click > 'inspect', or tap F12). In the inspector, go to the tab called 'Network'.
• Refresh the page.
• See the items printed on the web inspector. That's all the items that you are requesting everything you load the Google website! A lot will look like gibberish but they have their purpose.
• In the table, you should be able to right click and show the 'Method' column. Open that and see which of your requests are get and post.
• Continue to explore around the web and see what kind of requests you make!

Start a basic web application

There are tons of tutorials out there for starting up a basic web application for the language of your choice. Pick one one get started!

• For Ruby / Ruby on Rails

  • https://guides.rubyonrails.org/getting_started.html#creating-a-new-rails-project-installing-rails

• For Javascript / Express.js

  You'll want to install node first on your computer before proceeding to starting a new Express.js application

  • https://expressjs.com/en/starter/installing.html

For any of these options, you may run into operating system specific errors. For these you'll want to try searching for answers online first on how to resolve them.

Once you manage to install the basic application, start the server and make your first web request by going to the home page.

Making sense of the logs

Once you have managed to access the sample page, look at the logs (usually on the same Terminal page that you started the logs) and try to make sense of it. Specifically, look for

• What type of request GET, POST, etc.
• Which page the request tried to access
• What time it accessed
• Any other information that is interesting

Reading logs will go a long way to help you figure out what went wrong when making changes to your application.

Modify your application to show url params

Let's try to make your application a little more dynamic: Modify the function that handles the sample route so that it prints whatever you set on the URL params.

Example: when you access http://localhost:3000/?message=my+message, make it show "my message" on the browser.

• If you recall, url params look something like this ?message=hello that is added to the back of the URL. These give your application able to respond dynamically.