Surely you have heard at some point that someone sends a “request”. What is this “request”? Who sends it and actually to whom? What is it about when someone says “I got 500”? Let me try to explain it in simple words.
What communication is?
The terms “request” and “response” are most often used in communication context. Communication usually requires at least two interlocutors. Suppose you’re talking to your work colleague, your dialogue looks like this:
You: Hey, can you tell me the names of our customers?
Colleague: Sure, it’s company A, company B and company C.
You: Can you give me Company C contact number?
Colleague: Sure, 111 222 333.
Congratulations, you have just performed two-way communication in the request-response model! Two-way communication means that for each of your requests (“provide customer names”, “provide contact number”), your colleague confirmed that he received it (“sure”, “of course”) and then responded with the data you requested (“company A, company B….”, “111 222 333”).
Internet services works analogously. When you type
linkedin.com/in/rafał-orłowski-90721490
in the browser address bar, you are more or less saying: “Hey, Linkedin, give me the user rafał-orłowski-90721490 informations”. The difference is that you say it in machines language and not in human language. And how does this relate to a “request”?
What request is?
When you type anything in the browser address bar, you send a “request” of type GET to the given URL (I will explain what URL is in a moment). What is a “request type”? It is a way of expressing your intentions. Browsers are a kind of “http client” to simplify communication between humans and web services (e.g.: websites). For the purposes of this article, we will not go into what the “http” protocol is. In a nutshell: it’s a technical specification that describes how internet services can communicate with each other. Like the GSM standard describes how two phones communicate. Or like traffic regulations describes how to get a car from point A to point B in a safe manner.
Going back to the request types, a few basic ones are:
– GET – give me data. For example, show me the profile of user X.
– POST – I send you new data, please receive it. Every time you insert a new photo on instagram, you send a POST with an image file attached.
– UPDATE – I send you an update of your data, Example: you changed your name after marriage and want to update it on your social media.
– DELETE – delete your data. Fed up with social media – you delete your profile!
The data we send can take different forms. Sometimes it can be plain text, sometimes an image (a file in .jpg, .png or other graphic format), and sometimes structured data in one of the popular data formats, e.g: JSON or XML but about data formats another time.
Now that we know what we can send, let’s now consider where we can send our requests. In fact, our addressee can be any “Internet service”. Yes, yes, another difficult name, easy! I will explain. Remember the earlier example, with typing
linkedin.com/in/rafał-orłowski-90721490
in the browser bar? That’s the so-called URI (unified resource identifier), you may also encounter the term URL (unified resource locator), the difference between these terms is very subtle and rather philosophical than technical, so for the purposes of this article let’s assume that those two terms are the same. If you are very inquisitive and want to know more details take a look, for example, here.
A web service is really any “thing” that resides at a certain address (e.g.: linkedin.com).
What response is ?
Whenever we will send a request to the service we will get a response. The response consists of two key elements: response status and data. Let’s go back to the example of our conversation with a colleague:
You: Hey, can you give me the names of our customers?
Colleague: Sure, it’s company A, company B and company C.
In this case, our request (“provide the customers names”) was processed correctly (“sure”) and we were returned the data (“company A, company B and company C”). If we would receive the answer:
“I can’t. Only the department manager can get the full customers list” then our request was not processed correctly (“I can’t”) but our colleague was nice enough to give us some details: “Only the department manager can get the full customers list.” He could have been unkind and answered only “I can’t.”
In our “http world”, statuses are responsible for saying “sure, here are the data” or “unfortunately, I can’t”. Statuses are 3-digit numbers in the range 100-599 – a rather strange range, right?
Let me explain why such a non-standard range of values. The first digit (1,2,3,4 or 5) determines the “status category”, following:
1xx – the request was received, continuing process, don’t know when I will finish. In practice, very rare.
2xx – success! These are the statuses we would like to see the most. They mean that we managed to do exactly what we wanted to do.
3xx – redirected. That is, such a bit of a success, but our request had to be redirected to another place, and whether it succeeded or not we will find out in the response from that other place. It’s complicated, not to go into details, let’s consider it as a “request is ok, redirected to another URL”. In practice, used in more complex systems, to handle more unusual communication scenarios.
4xx – failed to process your request. Incorrect data were provided. In practice, this means that you’ve sent an invalid request.
5xx – failed to process your request, but this time it’s an error on the service side. In other words: your request seems to be ok, but the service for some reason was not able to do what you asked for. 5xx responses are usually the most mysterious.
All the standard statuses with explanations can be found on wikipedia.
As I mentioned earlier, in addition to the statuses response contains (usually) data. Similarly to “request”, there is no single answer for question “what data”. Depending on the service, it can be a file (sound, image, document), text (e.g.: the content of this article) or structured data in one of the popular formats (e.g.: JSON, XML).
Going back to the example of “Hey, can you tell me the names of our customers?”, subsequent responses can be consider as:
“Sure, it’s company A, company B and company C.” – Response status: 200 (ok), data: “company A, company B and company C”.
“I can’t. Only the department manager can get the full list of customers.” – response status: 403 (“forbidden”), data: “Only the department manager can get the full list of customers.”
“I can’t.” – response status: 500 (“internal server error”), no additional data.
How do you put it all together?
This may all sound very abstract but let’s try to sum it up somehow. Imagine that for some strange reason, the internet suddenly disappears (it could be an aliens attack, jamming signals around the world or little, sneaky shark-trolls that have bitten through all the cables, or any other absurd reason). Imagine also, that all the giant web portals (Google, LinkedIn, Instagram, etc.) still want to carry on their business. And the last assumption, the most absurd one but perfectly fitting for our article: web portals will not provide their services via the Internet (because it doesn’t exist) but via mail. The traditional mail. With envelopes, letters, postman on bicycle, mailboxes set up in different parts of the city…. So, Instagram is no longer “internet portal” but begins to be a „mailing…? portal?”, welcome to the new reality!
You’ve just taken a wonderful selfie with your Polaroid (for younger readers: it’s like an “instax” for old people), and of course you want to post it on Instagram. Yes, that “mailing Instagram.” So you take an envelope, address it: “Instagram. Menlo Park, California, US”, you put your photo in the envelope and drop it in the mailbox. After a few days, you receive a letter from Instagram that reads, “thank you for sending the photo, we received it and posted it on your profile.”
Congratulations, you just sent a request:
type: POST
URL: instagram.com
with image data, your photo
and received a response 201 (created).
Of course, it wouldn’t make sense if your loved ones couldn’t see your new analog selfie! So your best friend, right after waking up, reaches for an envelope, addresses it:
“Instagram. Menlo Park, California, US”
“Department of New Photos Shared by My Friends”
and sends it without any content. After another few days, he receives a letter back with an envelope filled with photos of his friends – including your selfie!
Translating this into http communication, your friend sent a request:
type: GET
URL: instagram.com/DepartmentNewPicturesSharedByMyFriends
without any content and in response received a 200 (ok) response and data: photos of your friends (graphic files).
This is how http communication works in a nutshell – sending “requests” and receiving “responses”. As you can see, it is much easier to conduct social media via the internet than traditional mail, although the mechanics of both solutions are very similar!
Can I send requests on my own?
Of course! You need an “http client” for this. This is nothing more than an application that will allow you to nicely address your envelope, put the contents inside and send the whole thing. The simplest http client is a web browser. Let’s check it out!
We need some service to correspondence with! Fortunately, good people have created example services that actually do nothing but simulate the behavior of real services. It means, we can send requests and receive responses but this does not result in any real action on these services.
One such examples would be dummyjson.com which simulates an e-commerce service and operates on data in JSON format.
If you paste into the browser bar https://dummyjson.com/products you will see all the products in our “dummy store”. Congratulations, you have just sent a GET to the URL https://dummyjson.com/products !
Unfortunately sending requests other than GET by browser, is quite inconvenient, it can be done but it requires a bit of magic and yet in the first paragraph I wrote “in simple terms”….
Therefore, let’s use another http client, for example: restninja.io – this is a website that acts as an http client. Yes, inception!!! but it works! You can of course choose any other client, e.g.: postman.com, insomnia.rest, httpie.io but rest ninja seems to me one of the simplest ones.
One of the others features of dummyjson.com is the ability to add new products to the store. To do so, you need to send a POST to the URL https://dummyjson.com/products/add with data in JSON format, which must include the “title” field. In the following screenshot you can see how to make such a request using rest ninja:
As an extremely attentive student of the http-ing art (there’s no such word, I just made it up) you’ve surely noticed the mysterious “headers” and “auth” tabs. These are the so-called requests “meta-data”. They contain all the additional information about our communication (more like technical details). Perhaps I will commit a separate article about them, the current one was supposed to be simple, so let me skip this part.
I encourage you to play around on your own with dummyjson documentation and restninja. Have fun!