HTTP, HTTPS, and APIs

Once TCP establishes a reliable connection, the two machines can safely exchange bytes. However, raw bytes have no inherent meaning. Without a shared protocol, the server would not know whether those bytes represent a file request, form submission, or something else entirely.

HTTP (Hypertext Transfer Protocol) defines a structured format for communication. A client sends a request (such as GET /index.html), and the server returns a response containing status information and data.

HTTP standardizes how resources are requested, how metadata is included, and how responses are formatted. This makes web communication predictable and interoperable across browsers, servers, and platforms.

In short, TCP ensures delivery. HTTP ensures understanding.

An HTTP request begins with a request line. This includes the method and the path. For example:
GET /users/123 HTTP/1.1
This tells the server what action is being requested and which resource is targeted.

The method communicates intent.

• GET retrieves data.
• POST submits new data.
• PUT updates existing data.
• DELETE removes data.

The headers provide additional context, such as content type (Content-Type), authentication credentials (Authorization), or information about the client (User-Agent).

Finally, some requests include a body. For example, a POST request may include JSON data being submitted to the server.

Together, these components create a predictable structure that servers can parse and interpret correctly.

An HTTP response begins with a status line, such as:
HTTP/1.1 200 OK

The status code communicates the result of the request.

• 200 means success.
• 404 means the resource was not found.
• 500 indicates a server-side error.

Next come the headers, which provide metadata about the response. These may include Content-Type (e.g., JSON or HTML), Content-Length, caching rules, or security policies.

Finally, the body contains the actual data requested — such as an HTML page, a JSON object, or a file.

The response structure ensures the client understands both what happened and what data was returned.

HTTP is designed as a stateless protocol. This means that when a client sends a request, the server handles it without assuming any prior context.

For example, if you load a webpage and then click a button, the second request does not automatically include memory of the first. Each request must contain all necessary information for the server to process it.

Statelessness simplifies scaling. Because servers do not rely on stored connection state, requests can be distributed across multiple machines behind a load balancer.

When applications need continuity — such as login sessions or shopping carts — they implement state explicitly using cookies, session identifiers, or authentication tokens.

HTTPS stands for HTTP over TLS (Transport Layer Security). Instead of sending HTTP messages in plain text, the data is encrypted before transmission.

With HTTPS, everything inside the HTTP request and response — including headers and body — is encrypted. This prevents attackers on the network from reading sensitive information such as passwords or tokens.

HTTPS also requires the server to present a valid digital certificate. The browser verifies this certificate against trusted Certificate Authorities to confirm the server’s authenticity.

Additionally, TLS applies cryptographic integrity checks to ensure that data has not been modified during transit.

In short, HTTPS protects confidentiality, authenticity, and integrity of web communication.

When a client connects to an HTTPS server, TLS first performs a handshake before any HTTP data is sent.

The process begins with a Client Hello. The client proposes supported cryptographic algorithms (cipher suites) and sends random data used later in key generation.

The server replies with a Server Hello, selecting the encryption parameters. It also sends its digital certificate, which contains its public key and is signed by a trusted Certificate Authority.

The client verifies the certificate and performs a key agreement process (such as Diffie-Hellman). Both sides independently derive the same shared secret without transmitting it directly.

Once the handshake completes, symmetric encryption keys are established, and all subsequent HTTP traffic is encrypted.

A digital certificate is issued by a trusted third party called a Certificate Authority (CA). The CA verifies that the organization requesting the certificate actually controls the domain name.

The certificate contains the server’s public key, along with identifying information about the domain. This public key is used during the TLS handshake to establish encrypted communication.

When your browser connects to a website, it checks whether the certificate is signed by a CA it already trusts. Browsers ship with a built-in list of trusted Certificate Authorities.

If the certificate is valid, not expired, and matches the requested domain, the browser proceeds with the secure connection. If not, it displays a warning.

Trust in HTTPS is therefore based on a chain:
You trust the CA → The CA trusts the server → You trust the server.

An API (Application Programming Interface) is a formal specification for how software components interact. It defines what operations are available and how those operations are accessed.

In web systems, APIs typically use HTTP. Clients send requests to specific endpoints (such as /users/123) using defined methods like GET or POST.

The API also defines the expected request format (for example, JSON in the request body) and the structure of the response format returned by the server.

Without APIs, systems would rely on undocumented conventions or tightly coupled integrations. APIs create clear boundaries, enabling independent development, scalability, and interoperability between services.

REST (Representational State Transfer) organizes APIs around resources, not actions. A resource is represented by a URL such as /users or /orders/123.

Instead of embedding verbs in the URL, REST uses HTTP methods to define the operation:

• GET retrieves data.
• POST creates new data.
• PUT updates existing data.
• DELETE removes data.

REST APIs are stateless, meaning each request contains all necessary information. The server does not rely on prior requests to process the current one.

Most REST APIs exchange data in JSON format, which is lightweight, human-readable, and easily parsed by machines.

This structure makes REST APIs consistent, scalable, and easy to reason about across distributed systems.

A 404 Not Found error means the server is reachable, but the requested route or resource does not exist. This is typically an application-level routing issue.

A 500 Internal Server Error indicates that the request reached the server, but something failed during execution — such as a crash, unhandled exception, or database failure.

A Connection Refused error occurs earlier in the stack. The client cannot establish a TCP connection, often because the server is down or no process is listening on the target port.

An SSL certificate error happens during the TLS handshake if the certificate is invalid, expired, or does not match the domain. The browser blocks the connection to protect the user.

A mixed content warning appears when an HTTPS page attempts to load HTTP resources. This breaks the security guarantees of HTTPS and is flagged by modern browsers.

Understanding where a failure occurs — application, transport, or TLS — is critical for effective debugging.