HTTP Lessons – Lesson 1 – Overview of basic concepts

/0 Comments/in /by

HTTP Lessons – Lesson 1 – Overview of basic concepts
HTTP Lessons – Lesson 2 – Architectural Aspects
HTTP Lessons – Lesson 3 – Client Identity
HTTP Lessons – Lesson 4 – Client Authentication Mechanisms
HTTP Lessons – Lesson 5 – Security
HTTP Lessons – Glossary

In this article, I will introduce you to the basics of HTTP.

But why HTTP?

Why should I read about HTTP you may ask yourself?

If you're a software developer, learning how they communicate will help you understand how to write better applications. If you're a systems architect or network administrator, you'll gain deeper knowledge of designing complex network architectures.

REST, a very important architectural style today, is based entirely on using HTTP features, making understanding HTTP even more crucial. If you want to build great RESTFULL applications, you must first understand HTTP.

So, you want to pass up the chance to learn and understand the basic concepts behind the World Wide Web and networking?

I hope you don't want to?

The focus of this article will be on explaining the most important parts of HTTP in the simplest possible terms. The idea is to organize all the useful information about HTTP in one place, saving you the time of digging through books and RFCs to find the information you need.

What will you learn in this article?

  • What exactly is HTTP?
  • Resources
  • How to transfer information between Web Client and Web Server
  • Messages and some message examples
  • MIME types
  • Request Methods
  • Titles
  • Status codes

Without further ado, let's get inside.

HTTP definition

The founder of HTTP is Tim Berners-Lee (who is also considered the inventor of the World Wide Web). Other figures important to the development of HTTP include Roy Fielding, the creator of the REST architectural style.

HyperText Transfer Protocol (HTTP) is the protocol applications use to communicate with each other. Essentially, HTTP is responsible for transferring media files across the internet between clients and servers. This includes HTML, images, text files, movies, and everything in between, and it does so quickly and reliably.

Because HTTP is used for communication at the application layer, it's an application protocol, not a transport protocol. Let's take a look at the network layers to refresh your memory:

Resources

Everything on the internet is a resource, and HTTP works with resources. This includes files, streams, services, and everything else. Your HTML page is a resource, your YouTube video is a resource, your spreadsheet in a web app, your journal page is a resource… you get the idea.

But how do you distinguish one source from another?

By giving them a URL (Uniform resource locators).

The URL points to a unique place where your browser can find the resource.

How messages are exchanged between the Web Client and Web Server

Every piece of content, every resource, resides on a Web server (HTTP server). These servers wait for an HTTP request to provide those resources.

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

Of course you need an HTTP client?

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

Messages and some message examples

So, what does the HTTP message look like?

Without further ado, let's look at some examples of HTTP messages:

GET Request

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

Post Request

POST /repos/CodeMazeBlog/ConsumeRestfulApisExamples/hooks?access_token=5643f4128a9cf974517346b2158d04c8aa7ad45f HTTP/1.1 Host: api.github.com Content-Type: application/json Cache-Control: no-cache { "url": "http://www.example.com/example", "events": [ "push" ], "name": "web", "active": true, "config": { "url": "http://www.example.com/example", "content_type": "json" } }

Here's an example of a GET and a POST request. Let's quickly review the different parts of these requests.

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

The next few lines represent the request headers. Request headers provide additional information such as the types of content included in the request, the content expected in the response, authorization information, and so on;

That's the end of the story for a GET request. A POST request can also have a body and carry additional information in the form of a body message. In this case, it's a JSON message containing additional information about how the GitHub webhook should be created for the given repo specified in the URI. This message is necessary for the webhook to be generated, so we use a POST request to provide this information to the GitHub API.

Request line and request headers, (carriage return and line feed \r\n) and there must be a single blank line containing only CRLF between the message headers and the message body.

Reference for HTTP request: https://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html

And what will we get in response to these requests?

Response message

HTTP/1.1 200 OK Server: GitHub.com Date: Sun, 18 Jun 2017 13:10:41 GMT Content-Type: application/json; charset=utf-8 Transfer-Encoding: chunked Status: 200 OK 14437404, "name": "web", "active": true, "events": [ "push" ], "config": { "content_type": "json", "insecure_ssl": "0", "url": "http://www.example.com/example" }, "updated_at": "2017-06-18T12:17:15Z", "created_at": "2017-06-18T12:03:15Z", "url": "https://api.github.com/repos/CodeMazeBlog/ConsumeRestfulApisExamples/hooks/14437404", "test_url": "https://api.github.com/repos/CodeMazeBlog/ConsumeRestfulApisExamples/hooks/14437404/test", "ping_url": "https://api.github.com/repos/CodeMazeBlog/ConsumeRestfulApisExamples/hooks/14437404/pings", "last_response": { "code": 422, "status": "misconfigured", "message": "Invalid HTTP Response: 404" } }, ]

The response message is structured almost identically to the request, except that the first line carries information about the response status.

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

Reference for HTTP response: https://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html

MIME types

MIME types are used as a standard way to identify file types on the internet. Your browser has a list of MIME types, and the same applies to web servers. This way, files can be transferred the same way regardless of operating system.

Originally developed for multimedia email, MIME stands for Multipurpose Internet Mail Extension. They have since been adapted for use with HTTP and many other protocols.

Each MIME type consists of a type, its 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

List of commonly used MIME types and subtypes In the HTTP reference you can find.

Request Methods

HTTP request methods (also called "actions") define the action to be performed on the resource. HTTP defines several request methods, the most well-known/used of which are GET and POST.

A request method can be either idempotent or non-idempotent. This is a simple term describing whether it's safe or unsafe to call the method multiple times on the same resource. In other words, this means that the GET method, which only retrieves information, should be idempotent by default. Repeated calls to GET on the same resource should not result in a different response. POST, on the other hand, is not idempotent.

Prior to HTTP/1.1, there were only three methods: GET, POST, and HEAD, and the HTTP/1.1 specification brought several more into play: OPTIONS, PUT, DELETE, TRACE, and CONNECT.

What each of these methods does HTTP Reference you can find more.

Headings

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

There are five types of headers in total:

  • General headings: These headers are useful to both the server and the client. A good example includes the date header field, which provides information about when the message was created.
  • Request titles: Specific to request messages. They provide additional information to the server. For example, the Accept: */* header field informs the server that the client is willing to accept any type of media.
  • Response titles: Specific to response messages. They provide additional information to the client. For example, the Allow: GET, HEAD, PUT header field tells the client which methods are allowed for the requested resource.
  • Entity headers: These headers relate to the body of the entity. For example, the Content-Type: text/html header lets the application know that the data is an HTML document.
  • Expansion headers: These are non-standard headers created by application developers. They are not part of HTTP, but should be tolerated.

List of frequently used request and response headers HTTP Reference you can find.

Status Codes

A status code is a three-digit number indicating the outcome of a request. It is followed by a human-readable reason explanation.

Some examples include:

  • 200 Successful.
  • 404 Not Found
  • 500 Server Error

Status codes are classified by range into five different groups.

Both status code classification and all status codes and their meanings HTTP Reference can be found.

Conclusion

Phew, that was a lot of information.

The knowledge you gain by learning HTTP won't directly help you solve a specific problem. However, it will give you an understanding of the fundamental principles of internet communication that you can apply to almost any problem at a higher level than HTTP. Whether it's REST APIs, web application development, or networking, you can now feel at least a little more confident when solving these types of problems.

Of course, HTTP is a pretty big topic to talk about and there's still a lot more to it than just the basics.

You can read about the architectural aspects of HTTP in part 2 of the HTTP series.

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

Next lesson: HTTP Lessons – Lesson 2 – Architectural Aspects

References:

Original Article: https://www.code-maze.com/http-series-part-1/

4.3 3 votes
Article Rating
You might also like
HTTP Lessons – Lesson 4 – Client Authentication Mechanisms
HTTP Lessons – Glossary
WordPress Xmlrpc Vulnerability and Solution
PHP Lesson 4 – Operators
HTTP Lessons – Lesson 2 – Architectural Aspects
PHP Lesson 2 – Variables
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Newest
Oldest Most Voted
Inline Feedbacks
View all comments