KAHIBARO
Discord Login Register ☰
☰

2.7. HTTP and HTTPS

Table of Contents

Why HTTP and HTTPS Matter for Backend Developers

When you build a backend, almost every client talks to your server using HTTP or HTTPS. Understanding them is critical, because:

This chapter focuses on what is specific to HTTP and HTTPS: how they look on the wire, how they differ, and what they mean for you as a backend developer.

What Is HTTP?

HTTP stands for HyperText Transfer Protocol. It is an application-level protocol that defines how clients and servers communicate text-based messages over the network.

A simple description:

You will see HTTP in:

HTTP is stateless: the server does not remember previous requests automatically. Each request is independent. Sessions and cookies (covered later in the course) are built on top of HTTP to simulate “remembering” users.

Versions of HTTP

There are several versions of HTTP in common use:

VersionMain ideaTypical use today
HTTP/1.0Simple, one request per connectionMostly historical, rarely used explicitly
HTTP/1.1Persistent connections, more headersStill extremely common in many backends
HTTP/2Multiplexing, header compression, binaryWidely used via browsers and CDNs
HTTP/3Uses QUIC over UDP, better performance on bad networksGrowing adoption, modern browsers

As a beginner, you mostly need to understand the concepts of HTTP and the message format. HTTP/1.1 is the easiest to read and reason about as text. HTTP/2 and HTTP/3 are more efficient, but high-level concepts like methods, URLs, headers, and status codes remain the same.

HTTP Request and Response Structure (High Level)

The details of the request/response cycle will be explained in a dedicated chapter, but here is a short look at how HTTP uses plain text messages.

An HTTP request consists of:

  1. A request line
    Example:
    GET /products?limit=10 HTTP/1.1
  2. Headers (zero or more)
    Example:
    Host: example.com
    User-Agent: Mozilla/5.0
    Accept: application/json
  3. A blank line
  4. An optional body (for example for POST or PUT)
    Example:
    { "name": "New product" }

An HTTP response consists of:

  1. A status line
    Example:
    HTTP/1.1 200 OK
  2. Headers
    Example:
    Content-Type: application/json
    Content-Length: 27
  3. A blank line
  4. An optional body
    Example:
    { "status": "success" }

You will work with all of these in detail in later chapters: HTTP Requests, HTTP Responses, HTTP Methods, HTTP Status Codes, and HTTP Headers.

What Is HTTPS?

HTTPS is HTTP over TLS. It is the same protocol (same methods, URLs, headers, status codes), but the data is encrypted and authenticated.

The S in HTTPS stands for Secure.

From your point of view as a backend developer:

Important rule: Always use HTTPS in production.
Sending passwords, tokens, or any sensitive data over plain HTTP is insecure and must be avoided.

Plain HTTP vs HTTPS: What Changes?

URL Scheme

The URL scheme tells the client whether to use HTTP or HTTPS:

SchemeExample URLDefault port
httphttp://example.com/api/users80
httpshttps://example.com/api/users443

When you open a site with https:// the browser:

With http:// it uses port 80 and sends HTTP in plain text without TLS.

Ports

You can change ports:

In practice, production sites usually stick to the defaults.

Visibility of Data

With HTTP:

With HTTPS:

What TLS Adds on Top of HTTP

HTTPS uses TLS (Transport Layer Security). You do not need the full cryptography details now, but you should know what benefits it provides.

TLS provides three main properties:

1. Encryption

Data between client and server is unreadable to anyone else.

Example:

http 
    POST /login HTTP/1.1
    Host: example.com
    Content-Type: application/json
    { "email": "user@example.com", "password": "mypassword123" }

A network sniffer can read this directly.

2. Integrity

TLS protects against modifications in transit.

3. Authentication (Server Identity)

TLS uses certificates to prove the identity of the server.

When you see a lock icon in the browser:

As a backend developer, you must ensure:

The Basic HTTPS Connection Flow

At a high level, this is what happens when a client uses HTTPS:

  1. Client connects to example.com:443 using TCP.
  2. Client and server perform a TLS handshake:
    • Negotiate cryptographic algorithms.
    • Exchange keys.
    • Validate the server certificate.
  3. Once the TLS handshake succeeds, a secure channel is established.
  4. Client sends HTTP requests inside this secure channel.
  5. Server sends HTTP responses back through the same secure channel.

The important part: your API code sees regular HTTP requests after decryption. Most of the TLS complexity is handled by web servers and libraries.

Example: HTTP vs HTTPS in Practice

Example 1: Simple GET for a public API

HTTP (insecure):

text 
GET /api/products HTTP/1.1
Host: api.example.com
Accept: application/json

HTTPS (secure):

Example 2: Login Request

HTTP:

http 
POST /login HTTP/1.1
Host: example.com
Content-Type: application/json
{ "email": "user@example.com", "password": "SuperSecret!" }

With plain HTTP:

With HTTPS:

This is why login forms and APIs must use HTTPS.

Why Browsers Push HTTPS

Modern browsers strongly favor HTTPS:

As a backend developer:

Example redirect:

http 
HTTP/1.1 301 Moved Permanently
Location: https://example.com/login

HTTP vs HTTPS: Summary Table

AspectHTTPHTTPS
Full nameHyperText Transfer ProtocolHTTP over TLS (Secure HTTP)
EncryptionNo, plain textYes, contents are encrypted
Default port80443
SecurityVulnerable to snooping and tamperingProtects confidentiality and integrity
CertificatesNot usedUses TLS certificates issued by CAs
Browser statusOften “Not secure” for forms or loginsLock icon, considered secure if correctly set up

Key statement:
Use HTTP for local development only, and HTTPS for any real users or sensitive data in production.

How This Affects Backend Development

You will usually see HTTPS in these contexts:

  1. Local development
    • Often use HTTP, for example: http://localhost:8000.
    • Less overhead, no need to manage certificates.
    • Traffic stays on your machine, so encryption is less critical.
  2. Staging and production
    • Must use HTTPS for real users and real data.
    • Typically configured via:
      • Cloud provider load balancers (AWS ALB, GCP, etc.),
      • Reverse proxies (Nginx, Traefik),
      • Services like Cloudflare.
    • You might use services like Let’s Encrypt for free certificates.
  3. Internal microservices
    • Sometimes use HTTP inside a private network, and HTTPS only at the public edge.
    • Sometimes use HTTPS between internal services as well, depending on security requirements.
  4. APIs and mobile apps
    • Mobile apps or SPA frontends call your backend using HTTPS.
    • You must provide HTTPS endpoints so clients can trust your server and protect user data.

Recognizing HTTP / HTTPS in Tools

Browser Developer Tools

curl

Using HTTP:

bash 
curl http://example.com/api/users

Using HTTPS:

bash 
curl https://example.com/api/users

Adding details:

bash 
curl -v https://example.com/api/users

The -v flag shows TLS handshake steps and certificate information.

Postman / API clients

Common Pitfalls for Beginners

Confusing HTTP with HTTPS

Remember:

Your application logic (routes, controllers, handlers) usually works the same. The difference is at the network and server configuration level.

Sending Sensitive Data Over HTTP

Never send:

over plain HTTP in real environments. Use HTTPS.

Incorrect Redirects

Common pattern:

Ensure:

Mixed Content

If your frontend is loaded over HTTPS, all its resources (APIs, images, scripts) should also be HTTPS.

If you try to call http:// API endpoints from an https:// page, browsers may block the request as “mixed content”.

Looking Ahead

In later chapters, you will dive into:

For all of these topics, the concepts are the same whether you use HTTP or HTTPS. HTTPS simply wraps all this communication in a secure envelope.

Quick Recap

Understanding this foundation will make it easier to reason about APIs, security, and deployment as you move through the rest of the course.

Views: 10

Comments

Please login to add a comment.

Don't have an account? Register now!

© 2025 Kahibaro
Visitors: 3067 / 24h
Impressum / Imprint
Datenschutz / Data Policy