top of page
  • Writer's pictureShannon

APIs Aren't Just For Devs Pt. 7 - HTTP Responses

Ok here I am on my 7th post, trying to help you make sense of APIs. A lot of us managed to become a whole lot more technical and develop careers without the core fundamentals taught within a computer science degree. I often wonder if I would've stuck with the degree the way that computer science is typically taught, had I selected that for my major. I suppose that's something to marinate over at another date and time.

At any rate, if you're arriving here by way of this post, please take a peek at the series as it stands: APIs Aren't Just For Devs Pt. 1 - API Definition (

So where are we now, related to the posts? HTTP responses! Remember to think of an API as a mechanism that allows 2 parties (think of it as an end user who is making a request from a social media platform like Facebook, Instagram, or LinkedIn) to communicate. The request is part of it, and we just covered that in part 6 (linked above) of this series. Then there's the corresponding response that the end user (to use my example above) receives from the social media platform they're requesting information from.

Let's think of it like this: Imagine you are sending a letter to a friend, and you ask them a question. The HTTP response is like the letter your friend sends back to answer your question.

When you visit a website or use an app on the internet, your device (like a computer or a phone) sends a message called an HTTP request to a server. It's like writing a letter to the server, asking for some information or a specific page.

The server receives your letter (the HTTP request), reads it, and then prepares a special letter called an HTTP response just for you. This letter contains the information you requested or the web page you wanted to see. Think of this as searching for someone on LinkedIn you met at a conference as an easy-to-understand example.

The HTTP response is like a package with two important parts:

  1. Status Line: This is like the title of the letter. It tells you if your request was successful or not. For example, it might say "200 OK" if everything went well, which means you got the information you asked for. But if there's an error, it might say something like "404 Not Found," which means the server couldn't find what you were looking for. Refer to part 5 of this blog series (linked above).

  2. Message Body: This is the main part of the letter. It contains the actual information you wanted, like the text, images, the profile, or videos you asked for. It's like the answers to your questions that your friend writes in the letter.

Once your device receives this HTTP response, it understands what the server is saying and uses the information to show you the web page or perform the action you wanted. It's like reading the letter from your friend and learning what they have to say.

An easy way to understand this is to think of HTTP responses as special letters you receive from the internet when you ask for something and they contain all the information you need to see or use the website/app correctly.

Recent Posts

See All

Enforcing Design Consistency with Azure Policy and Tags

Azure Policy allows you to create, assign, and manage policies in Azure (that definition feels a little like one of those awful definitions in Merriam Webster, right?). These policies enforce differen


bottom of page