Click here to Skip to main content
13,350,029 members (50,101 online)
Click here to Skip to main content
Add your own
alternative version


82 bookmarked
Posted 18 Jun 2017

The HTTP series (Part 1): Overview of the basic concepts

, 1 Aug 2017
Rate this:
Please Sign up or sign in to vote.
Basics of HTTP

In this article, you will learn the basics of HTTP.

But Why HTTP?

Why should I read about the HTTP you may ask yourself?

Well, if you are a software developer, you will understand how to write better applications by learning how they communicate. If you are a system architect or network admin, you will get deeper knowledge on designing complicated network architectures.

The REST, which is a very important architectural style nowadays is relying completely upon utilizing HTTP features, so that makes HTTP even more important to understand. If you want to make great RESTful applications, you must understand HTTP first.

So are you willing to pass on the chance to understand and learn the fundamental concepts behind World Wide Web and network communication?

I hope not. 🙂

The focus of the article will be on explaining the most important parts of HTTP as simply as humanly possible. The idea is to organize all the useful information about HTTP in one place, to save you the time of going through the whole books and RFCs to find the information you need.

This is the first article of the HTTP series. It will give you a short introduction of the most important concepts of the HTTP.

You will learn about:

Without further ado, let’s dive in.

HTTP Definition

The founder of HTTP is Tim Berners-Lee (the guy also is considered to be the inventor of the World Wide Web). Among other names important to the development of the HTTP is also Roy Fielding, who is also the originator of the REST architectural style.

The Hypertext Transfer Protocol is the protocol that applications use to communicate with each other. In essence, the HTTP is in charge of delegating all of the internets media files between clients and servers. That includes HTML, images, text files, movies and everything in between. And it does this quickly and reliably.

HTTP is the application protocol and not the transport protocol because it is used for the communication in the application layer. To jog your memory here is how the Network Stack looks like.

Network stack

From this image, you can clearly see that the HTTP is the application protocol and that TCP works on the transport layer.



Everything on the internet is a resource, and the HTTP works with resources. That includes files, streams, services and everything else. HTML page is a resource, a youtube video is a resource, your spreadsheet of daily tasks on a web application is a resource… You get the point.

And how do you differentiate one resource from another?

By giving them URLs (Uniform resource locators).

URL points to the unique location where your browser can find the resource.

How are Messages Exchanged between Web Client and Web Server

Every piece of content, every resource lives on some Web server (HTTP server). These servers are expecting an HTTP request to provide those resources.

But how do you request a resource from a Web server?

You need an HTTP client of course. 🙂

You are using an HTTP client right now to read this article. Web browsers are HTTP clients. They communicate with HTTP servers to retrieve the resources to your computer. Some of the most popular clients are Google’s Chrome, Mozilla’s Firefox, Opera, Apple’s Safari, and unfortunately still infamous Internet Explorer.

Messages and Some Message Examples

So how does the HTTP message look like?

Without talking too much about it, here are some examples of HTTP messages:

GET Request

GET /repos/CodeMazeBlog/ConsumeRestfulApisExamples HTTP/1.1
Content-Type: application/json
Authorization: Basic dGhhbmtzIEhhcmFsZCBSb21iYXV0LCBtdWNoIGFwcHJlY2lhdGVk
Cache-Control: no-cache

POST Request

POST /repos/CodeMazeBlog/ConsumeRestfulApisExamples/
hooks?access_token=5643f4128a9cf974517346b2158d04c8aa7ad45f HTTP/1.1
Content-Type: application/json
Cache-Control: no-cache

  "url": "",
  "events": [
  "name": "web",
  "active": true,
  "config": {
    "url": "",
    "content_type": "json"

Here is the example of one GET and one POST request. Let’s go quickly through the different parts of these requests.

The first line of the request is reserved for the request line. It consists of request method name, request URI, and HTTP version.

Next few lines represent the request headers. Request headers provide additional information to the requests, like content types request expects in response, authorization information, etc.

For the GET request, the story ends right there. POST request can also have a body and carry additional information in the form of a body message. In this case, it is a JSON message with additional information on how the GitHub webhook should be created for the given repo specified in the URI. That message is required for the webhook creation so we are using POST request to provide that information to the GitHub API.

Request line and request headers must be followed by <CR><LF> (carriage return and line feed \r\n), and there is a single empty line between message headers and message body that contains only CRLF.

Reference for HTTP request:

And what do we get as a response to these requests?

Response Message

HTTP/1.1 200 OK
Date: Sun, 18 Jun 2017 13:10:41 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Status: 200 OK
X-RateLimit-Limit: 5000
X-RateLimit-Remaining: 4996
X-RateLimit-Reset: 1497792723
Cache-Control: private, max-age=60, s-maxage=60

    "type": "Repository",
    "id": 14437404,
    "name": "web",
    "active": true,
    "events": [

    "config": {
      "content_type": "json",
      "insecure_ssl": "0",
      "url": ""
    "updated_at": "2017-06-18T12:17:15Z",
    "created_at": "2017-06-18T12:03:15Z",
    "url": "",
    "last_response": {
      "code": 422,
      "status": "misconfigured",
      "message": "Invalid HTTP Response: 404"

The response message is pretty much structured the same as the request, except the first line that is called the status line, which surprising as it is, carries information about the response status. 🙂

The status line is followed by the response headers and response body.

Reference for HTTP response:

MIME Types

MIME types are used as a standardized way to describe the file types on the internet. Your browser has a list of MIME types and same goes for web servers. That way files can be transferred the same way regardless of the operating system.

Fun fact is that MIME stands for Multipurpose Internet Mail Extension because they were originally developed for the multimedia email. They were adapted to be used for HTTP and several other protocols since.

Every MIME type consists of a type, subtype and a list of optional parameters in the following format: type/subtype; optional parameters.

Here are a few examples:

Content-Type: application/json
Content-Type: text/xml; charset=utf-8
Accept: image/gif

You can find the list of commonly used MIME types and subtypes in the HTTP reference.

Request Methods

HTTP request methods (referred to also as “verbs”) define the action that will be performed on the resource. HTTP defines several request methods of which the most commonly known/used are GET and POST methods.

A request method can be idempotent or not idempotent. This is just a fancy term for explaining that method is safe/unsafe to be called several times on the same resources. In other words, that means that GET method, that has a sole purpose of retrieving information, should by default be idempotent. Calling GET on the same resource over and over should not result with a different response. On the other hand, POST method is not an idempotent method.

Prior to HTTP/1.1, there were just three methods: GET, POST and HEAD, and the specification of the HTTP/1.1 brought a few more in the play: OPTIONS, PUT, DELETE, TRACE and CONNECT.

Find more what each one of these methods does in the HTTP Reference.


Header fields are colon-separated name-value fields you can find just after the first line of request or response message. They provide more context to the HTTP messages and ensure clients and servers are appropriately informed about the nature of the request or response.

There are five types of headers in total:

  • General headers: These headers are useful to both server and client. One good example is the Date header field which provides the information about the time of the message creation.
  • Request headers: Specific to the request messages. They provide the server with additional information. For example, Accept: */* header field informs the server that the client is willing to receive any media type.
  • Response headers: Specific to the response messages. They provide the client with additional information. For example, Allow: GET, HEAD, PUT header field informs the client which methods are allowed for the requested resource.
  • Entity headers: These headers deal with entity body. For example, Content-Type: text/html header lets the application know that the data is HTML document.
  • Extension headers: These are nonstandard headers constructed by application developers. They are not the part of HTTP but need to be tolerated.

You can find the list of commonly used request and response headers in the HTTP Reference.

Status Codes


The status code is a three digit number that denotes the result of a request. It is followed by the reason phrase which is humanly readable status code explanation.

Some examples include:

  • 200 OK
  • 404 Not Found
  • 500 Internal Server Error

The status codes are classified by the range in five different groups.

Both status code classification and the entire list of status codes and their meaning can be found in the HTTP Reference.


Phew, that was a lot of information.

The knowledge you gain by learning HTTP is not the kind that helps you to solve some problem directly. But it gives you the understanding of the underlying principle of the internet communication which you can apply to almost every other problem on the higher level than HTTP. Whether it is REST, APIs, web application development or network, you can now be at least a bit more confident while solving these kinds of problems.

Of course, HTTP is a pretty large topic to talk about and there is still a lot more to it than the basic concepts.

Read about the architectural aspects of HTTP in the part 2 of the HTTP series.

Was this article helpful to you? Please leave the comment and let me know.


The post HTTP: Overview of the basic concepts (Part 1) appeared first on Code Maze.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Code Maze
Software Developer
Serbia Serbia
Hi, my name is Vladimir Pecanac, and I am full time .NET developer and software development enthusiast. I use this tiny part of the internet to share the things I learn in hope of both helping others and deepening my own knowledge of the topics I write about.

The best way to learn is to teach.

I feel that many technical articles are written in an unnecessarily complicated way to sound more authoritative and serious. My goal is to change that trend and write down-to-earth, simple articles that are easy to read and understand by anyone.

Having said all that, I hope you will enjoy reading my articles and learn something new in the process.

If you liked my articles, you can read more at my blog Code Maze.

You may also be interested in...


Comments and Discussions

PraiseThe HTTP series (Part 1) - so far so good.... Pin
Fergal197026-Jul-17 23:53
memberFergal197026-Jul-17 23:53 
GeneralRe: The HTTP series (Part 1) - so far so good.... Pin
Vladimir Pecanac27-Jul-17 0:06
professionalVladimir Pecanac27-Jul-17 0:06 
PraiseThanks for a good explanation ! Pin
avanicc26-Jul-17 2:33
memberavanicc26-Jul-17 2:33 
GeneralRe: Thanks for a good explanation ! Pin
Vladimir Pecanac26-Jul-17 11:50
professionalVladimir Pecanac26-Jul-17 11:50 
Generalgood Pin
Tony Lee Cn26-Jul-17 0:26
memberTony Lee Cn26-Jul-17 0:26 
GeneralRe: good Pin
Vladimir Pecanac26-Jul-17 1:52
professionalVladimir Pecanac26-Jul-17 1:52 
PraiseGood explanation ! Pin
Member 1167881524-Jul-17 17:13
memberMember 1167881524-Jul-17 17:13 
GeneralRe: Good explanation ! Pin
Vladimir Pecanac24-Jul-17 20:50
professionalVladimir Pecanac24-Jul-17 20:50 
QuestionThanks Pin
Michael29302018-Jul-17 19:46
memberMichael29302018-Jul-17 19:46 
AnswerRe: Thanks Pin
Vladimir Pecanac18-Jul-17 22:32
professionalVladimir Pecanac18-Jul-17 22:32 
QuestionThis is excellent Pin
Michael Breeden17-Jul-17 10:07
memberMichael Breeden17-Jul-17 10:07 
AnswerRe: This is excellent Pin
Vladimir Pecanac17-Jul-17 20:59
professionalVladimir Pecanac17-Jul-17 20:59 
SuggestionA grammatical nit to pick Pin
Twixtfanatic14-Jul-17 20:12
memberTwixtfanatic14-Jul-17 20:12 
GeneralRe: A grammatical nit to pick Pin
Vladimir Pecanac14-Jul-17 22:43
professionalVladimir Pecanac14-Jul-17 22:43 
QuestionNice article Pin
Ancient Zygote14-Jul-17 11:59
memberAncient Zygote14-Jul-17 11:59 
AnswerRe: Nice article Pin
Vladimir Pecanac14-Jul-17 22:32
professionalVladimir Pecanac14-Jul-17 22:32 
GeneralRe: Nice article Pin
Ancient Zygote15-Jul-17 6:39
memberAncient Zygote15-Jul-17 6:39 
GeneralRe: Nice article Pin
Vladimir Pecanac15-Jul-17 7:46
professionalVladimir Pecanac15-Jul-17 7:46 
QuestionGreat Overview Pin
daveo1234514-Jul-17 8:27
memberdaveo1234514-Jul-17 8:27 
AnswerRe: Great Overview Pin
Vladimir Pecanac14-Jul-17 9:37
professionalVladimir Pecanac14-Jul-17 9:37 
GeneralMy vote of 5 Pin
Ehsan Sajjad12-Jul-17 0:46
professionalEhsan Sajjad12-Jul-17 0:46 
GeneralRe: My vote of 5 Pin
Vladimir Pecanac12-Jul-17 2:15
professionalVladimir Pecanac12-Jul-17 2:15 
Praisegreat explanation dude! Pin
Member 104881027-Jul-17 10:43
memberMember 104881027-Jul-17 10:43 
GeneralRe: great explanation dude! Pin
Vladimir Pecanac10-Jul-17 5:56
professionalVladimir Pecanac10-Jul-17 5:56 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web01 | 2.8.180111.1 | Last Updated 1 Aug 2017
Article Copyright 2017 by Code Maze
Everything else Copyright © CodeProject, 1999-2018
Layout: fixed | fluid