The primary way that we talk on the internet is through requests.
Let’s say it’s the 1980s, and we want to apply to college. However, before we apply, we want to get some information about the college. We send a letter to the college asking for information, and the college sends back a flyer with some information.
Similarly, requests work the same way. When we want to communicate with a server, we send requests to that server, the server processes our request, and sends back a response.
There are many different types of requests, including GET, POST, PUT, DELETE, and many more. But for now, I’m just going to introduce you to GET requests, the simplest and most common type of request on the internet.
GET Requests
A GET request is pretty straightforward, it’s just you requesting a specific resource from a server.
Every time you open up Google Chrome or Firefox or whatever, and type a URL into the address bar, you’re sending a GET request to that URL.
Type an address, click enter, and that’s it! You’ve just sent a GET request. When we go to https://google.com/, we’re greeted with the Google search webpage.
But that’s kind of boring. We don’t want the Google search webpage. We want search results. We want the server to respond back to our request in a specific way based on what we want. But how can we do that?
That’s when queries come in. Queries are parameters that we can embed into our URL to tell the server what we want.
For example, when we type https://google.com/search?q=cute+cat+videos into our address bar, we’re telling the server to give us https://google.com/search, with a query “q” of “cute+cat+videos”.
(Note that Google uses plus signs in place of spaces because URLs don’t support spaces.)
That’s basically all there is to it. Simple right?
GET Request Processing
GET requests are pretty versatile: You can get information, you can get specific information, and you can tell the server what information you want to get.
A few guidelines before you go crazy with GET requests:
GET requests are designed to be consistent, or idempotent. That means that under any condition, sending two of the same GET requests should result in getting the same response.* (This also helps with caching so if the same URL is getting requested multiple times, our server can cache the response instead of recomputing it every time!)
*(We’re assuming that the resource isn’t constantly updating. For things like search engines, website results update everyday!)
Also, keep in mind that GET requests are meant to GET data, not to SEND data or PERFORM actions. To send data, we use POST requests (which you will learn later.)
But wait: We have queries, so why can’t we send data to the server? And you’re right: You can send data using GET requests through queries, but it’s not recommended.
Let’s say that there exists a website called https://crappy.commerce that uses GET requests to login. To login to crappy.commerce, users can use the following GET request: https://crappy.commerce/?action=login&username=hacker&password=hello123 .
We can already see why SENDING data using GET requests is a bad idea: The password is literally in the URL! When we use GET requests, our queries are visible, and while various security protocols have ensured that these queries are kept secret, it could have unintended side effects.
But putting that aside, there’s an even bigger flaw: Clicking on the link will log us into whichever account is specified in the URL. What if we tricked someone into clicking our link, and then they add their credit card information? They’ve just added their credit card information onto our account, and they don’t even know it!
That’s another flaw with sending data, or in this case, performing actions with GET requests: GET requests are simple and easy to send, and attackers can use that to their advantage.
Obviously the example above is pretty extreme, and will probably not happen in real life, (at least I hope so…?) but the takeaway here is that GET requests are for GETTING, and for GETTING only.
Conclusion
Let’s go back to the college analogy on the top of the page: That’s basically the physical equivalent of a GET request! But instead of sending a letter, we send a GET request instead, and instead of receiving a flyer, we get the HTML of the website.
Ok, so let’s start working with requests!!!
Nope. Before we start sending requests in our applications, we need to learn about another concept first: Asynchronous code execution.
