DEV Community

Cover image for What Is HTTP & HTTPS ?
Mohamed Elmorsy
Mohamed Elmorsy

Posted on

What Is HTTP & HTTPS ?

Every time you open a browser and visit a website, something invisible but essential happens in the background — your browser and the server are having a conversation. The rules that govern that conversation are called HTTP. And when that conversation needs to be private, we add a layer of security on top, giving us HTTPS.

This is the foundation every web developer should understand before writing a single line of backend code.


What Is HTTP?

HTTP stands for HyperText Transfer Protocol. It is an application-layer protocol that defines how messages are formatted and transmitted between a client (like your browser) and a server (the machine hosting a website or API).

Think of HTTP as a language — both the client and server speak it so they can understand each other. Without HTTP, a browser would have no standard way to ask for a webpage, and a server would have no standard way to respond.

Key characteristics:

  • Stateless — each request is independent; the server has no memory of previous requests
  • Text-based — requests and responses are human-readable plain text
  • Request/Response model — the client always initiates; the server always responds

Want a visual walkthrough? Traversy Media's HTTP Crash Course & Exploration is one of the best video explanations out there. Highly recommended before moving on.


How HTTP Works: The Request/Response Cycle

Every HTTP interaction follows a strict two-step pattern.

Step 1 — The Request

The client (your browser or app) sends a request to the server. A raw HTTP request looks like this:

GET /users/123 HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer <token>
Enter fullscreen mode Exit fullscreen mode

It has three parts:

Part Example Purpose
Request Line GET /users/123 HTTP/1.1 Method + path + protocol version
Headers Content-Type: application/json Metadata about the request
Body { "name": "Anne" } Data sent with the request (POST/PUT only)

Step 2 — The Response

The server receives the request, processes it, and sends back a response:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 123,
  "name": "Anne",
  "email": "anne@example.com"
}
Enter fullscreen mode Exit fullscreen mode

It has three parts too:

Part Example Purpose
Status Line HTTP/1.1 200 OK Protocol version + status code
Headers Content-Type: application/json Metadata about the response
Body { "id": 123, ... } The actual data returned

HTTP Status Codes

Status codes are the server's way of telling the client what happened. They are grouped into five families:

![[Pasted image 20260529223910.png]]

Range Category Common Examples
1xx Informational 100 Continue
2xx Success 200 OK, 201 Created, 204 No Content
3xx Redirection 301 Moved Permanently, 304 Not Modified
4xx Client Error 400 Bad Request, 401 Unauthorized, 404 Not Found
5xx Server Error 500 Internal Server Error, 503 Service Unavailable

Rule of thumb: If it starts with 4, you (the client) did something wrong. If it starts with 5, the server broke.


Making HTTP Requests in Go

Go's net/http package gives you everything you need. Here is a complete example that makes a GET request and reads the response body:

package main

import (
    "fmt"
    "io"
    "net/http"
)

func main() {
    resp, err := http.Get("https://api.example.com/users/123")
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()

    // Read the response body
    body, err := io.ReadAll(resp.Body)
    if err != nil {
        panic(err)
    }

    fmt.Printf("Status : %s\n", resp.Status)
    fmt.Printf("Body   : %s\n", string(body))
}
Enter fullscreen mode Exit fullscreen mode

You can also inspect headers directly:

fmt.Println(resp.Header.Get("Content-Type"))
Enter fullscreen mode Exit fullscreen mode

What Is HTTPS?

HTTPS is simply HTTP with a security layer on top — specifically TLS (Transport Layer Security), the modern successor to SSL.

Without HTTPS, all data travels as plain text. Anyone sitting between the client and server — on a public Wi-Fi network, for example — can read it. HTTPS solves this by encrypting the data before it travels.

HTTPS gives you three guarantees:

  • Confidentiality — data is encrypted; no one in the middle can read it
  • Integrity — data cannot be tampered with in transit without detection
  • Authentication — you can trust you are actually talking to the right server

How HTTPS Works: The TLS Handshake

Before any encrypted data is sent, the client and server perform a TLS handshake — a brief negotiation to agree on encryption settings and verify identities.

TLS/SSL Handshake Diagram

Here is a simplified view of the steps:

1. CLIENT HELLO  →  "Here are the TLS versions and ciphers I support."

2. SERVER HELLO  ←  "OK, let's use TLS 1.3 and this cipher suite."
                    "Here is my SSL certificate (signed by a trusted CA)."

3. CLIENT        →  Verifies the certificate is valid and trusted.
                    Generates a session key and sends it encrypted.

4. BOTH SIDES       Derive the same symmetric session key.

5. ENCRYPTED        All further communication is encrypted.
   CHANNEL ✓
Enter fullscreen mode Exit fullscreen mode

After the handshake, everything works exactly like regular HTTP — except every message is encrypted. That is all HTTPS is: HTTP + TLS encryption.


HTTP vs HTTPS

Feature HTTP HTTPS
Port 80 443
Encryption ✗ None ✓ TLS/SSL
Data in transit Plain text Encrypted
Certificate required ✓ (from a CA like Let's Encrypt)
URL prefix http:// https://
Browser indicator ⚠ Not Secure 🔒 Secure
SEO ranking Lower Higher (Google preference)
Use case Internal tooling only Everything public-facing

Practical note: There is no valid reason to use plain HTTP for a public-facing service in 2025. Free SSL certificates are available from Let's Encrypt. Tools like Caddy and Nginx handle the setup automatically.


Making HTTPS Requests in Go

Go's http.Get and http.Client use HTTPS by default when you pass an https:// URL — no extra setup needed. The TLS handshake happens automatically under the hood.

package main

import (
    "fmt"
    "io"
    "net/http"
)

func main() {
    // Go handles TLS automatically — just use https://
    resp, err := http.Get("https://api.example.com/users/123")
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()

    body, err := io.ReadAll(resp.Body)
    if err != nil {
        panic(err)
    }

    fmt.Printf("Status : %s\n", resp.Status)
    fmt.Printf("Body   : %s\n", string(body))
}
Enter fullscreen mode Exit fullscreen mode

If you need to skip TLS verification in a local development environment (never in production), you can configure the transport:

package main

import (
    "crypto/tls"
    "fmt"
    "io"
    "net/http"
)

func main() {
    // ⚠ Only use InsecureSkipVerify in local dev — never in production
    transport := &http.Transport{
        TLSClientConfig: &tls.Config{InsecureSkipVerify: true},
    }
    client := &http.Client{Transport: transport}

    resp, err := client.Get("https://localhost:8443/health")
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()

    body, _ := io.ReadAll(resp.Body)
    fmt.Printf("Status : %s\n", resp.Status)
    fmt.Printf("Body   : %s\n", string(body))
}
Enter fullscreen mode Exit fullscreen mode

Summary

Concept What It Is
HTTP The protocol defining how clients and servers communicate
Request A client message containing a method, path, headers, and optional body
Response A server reply containing a status code, headers, and optional body
Status Code A 3-digit number telling the client what happened
HTTPS HTTP with TLS encryption layered on top
TLS Handshake A negotiation that sets up the encrypted channel before data flows

Further Reading & Watch


Now you know how the web actually talks. HTTP is the language; HTTPS is the same language, spoken in a locked room. Every API you build, every http.Get you write, every status code you return — all of it runs on top of what you just learned.

But what if there was a way to ditch the rigid rules of REST entirely and let the client decide exactly what data it gets back — not one field more, not one field less? That is the problem GraphQL was built to solve. And it changes how you think about APIs completely. See you in the next one.b

Top comments (0)