But do you know what actually happens when your application sends a request? What travels through the wire? Why does HTTP/2 make things faster? Why do WebSockets exist when HTTP already works? What makes Protocol Buffers different from JSON at a fundamental level?

And when you're designing a system, how do you decide which communication approach to use?

These are the questions this handbook answers.

This isn't a beginner's guide to APIs. This is a deep dive into how clients and servers actually communicate: the protocols, the trade-offs, the history of why each approach was built, and the engineering thinking behind choosing one over another.

By the end, you won't just know what these technologies are. You'll understand why they exist, how they work at a level that makes you a better engineer, and how to make deliberate architectural decisions about communication in your systems.

Table of Contents

• The Foundation: How Two Machines Talk to Each Other

• HTTP/1.1: The Protocol That Built the Web

• The Problems HTTP/1.1 Could Not Solve

• HTTP/2: Rebuilding the Foundation

• HTTP/3 and QUIC: The Next Evolution

• Data Formats: How Information Is Encoded

• REST: The Architecture That Took Over the World

• The Limits of REST

• GraphQL: Letting the Client Decide

• WebSockets: When HTTP Is Not Enough

• Server-Sent Events: The Simpler Real-Time Option

• Protocol Buffers: A New Language for Data

• gRPC: Remote Procedure Calls at Scale

• The Complete Comparison

• How to Choose: The Engineering Decision Framework

• Conclusion

The Foundation: How Two Machines Talk to Each Other

Before any protocol, data format, or architectural style enters the picture, two machines need to establish a connection. Understanding this foundation makes everything else click.

IP Addresses and Ports

Every device on a network has an IP address: a unique identifier that works like a postal address. When your application sends a request to api.example.com, the first thing that happens is a DNS lookup, which translates that human-readable name into an IP address like 93.184.216.34. That IP address is where the packet is going.

But an IP address alone isn't enough. A single server might be running dozens of different services simultaneously: a web server, a database, an email server, an SSH daemon.

Ports tell the operating system which service should handle the incoming connection. Port 80 is the conventional port for HTTP. Port 443 is for HTTPS. Port 5432 is for PostgreSQL. Port 22 is for SSH. When you call api.example.com/users, you are actually calling api.example.com:443/users. The browser fills in the port automatically.

TCP: The Reliable Foundation

Most web communication runs over TCP (Transmission Control Protocol). TCP is a connection-oriented protocol, which means before any data is exchanged, both parties go through a handshake to establish a connection.

The TCP handshake works in three steps, which is why it's called the three-way handshake:

Client                    Server
  |                          |
  |-------- SYN ----------->|   "I want to connect"
  |                          |
  |<------- SYN-ACK --------|   "Okay, I acknowledge. Ready?"
  |                          |
  |-------- ACK ----------->|   "Great, let's go"
  |                          |
  [Connection established]

SYN stands for synchronize. ACK stands for acknowledge. After these three packets, the connection exists and data can flow.

TCP guarantees three things that make it the foundation of reliable communication:

1. Delivery: if a packet is lost in transit, TCP detects this and retransmits it automatically. The application layer never has to worry about lost packets.

2. Order: packets arrive in the same order they were sent. If packets arrive out of order (which happens frequently on real networks), TCP reorders them before delivering them to the application.

3. Error detection: every TCP packet includes a checksum. If the data is corrupted in transit, TCP detects and discards the corrupted packet, then requests a retransmission.

This reliability comes at a cost: the overhead of the handshake, the acknowledgment packets, and the retransmission logic.

For many use cases, this cost is worth it. For some (live video streaming, online gaming, DNS lookups), UDP (User Datagram Protocol) is preferred because it sends packets without any of this overhead, accepting some loss in exchange for speed. HTTP/3, which we'll cover later, is built on a protocol that brings reliability to UDP.

TLS: Encrypting the Connection

On the modern web, most connections use HTTPS rather than plain HTTP. The S stands for Secure, and the security is provided by TLS (Transport Layer Security), the successor to SSL.

TLS adds an additional handshake on top of the TCP connection. During the TLS handshake:

1. The client and the server agree on which version of TLS to use and which encryption algorithms to support

2. The server presents its digital certificate (issued by a trusted Certificate Authority)

3. The client verifies the certificate is valid and belongs to the server it intended to reach

4. They exchange encryption keys using asymmetric cryptography

5. From that point forward, all communication is encrypted with symmetric encryption

The TLS handshake adds latency. In TLS 1.2, it takes two round trips before any application data can flow. TLS 1.3, released in 2018, reduced this to one round trip, and even supports zero round-trip resumption for returning connections.

Understanding TCP and TLS matters because every protocol we discuss runs on top of them (until HTTP/3, which changes the underlying transport). When people talk about the "overhead" of HTTPS or the "cost" of establishing a connection, they're talking about the time and packets spent on these handshakes before a single byte of your actual request travels.

HTTP/1.1: The Protocol That Built the Web

HTTP (HyperText Transfer Protocol) was invented by Tim Berners-Lee in 1991 to transfer HTML documents between computers. HTTP/1.0 was simple: one request per connection, then the connection closes.

HTTP/1.1, standardized in 1997, brought significant improvements and became the dominant version of HTTP for nearly two decades. It introduced persistent connections (keep connections open across multiple requests), chunked transfer encoding, and more sophisticated caching mechanisms.

How an HTTP/1.1 Request Works

An HTTP request is a text message with a specific structure:

POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...
Accept: application/json
Content-Length: 45
User-Agent: MyApp/2.0

{"name": "John Smith", "email": "john@example.com"}

The first line is the request line: the HTTP method (POST), the path (/api/users), and the protocol version.

Below that are the headers: key-value pairs that provide metadata about the request. The host, the content type, the authorization token, what format the client accepts, and how large the body is.

After a blank line comes the body: the actual data being sent.

The server processes this and responds:

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/users/usr_789
Date: Mon, 21 Jul 2026 09:15:00 GMT
Content-Length: 89

{"id": "usr_789", "name": "John Smith", "email": "john@example.com", "created_at": "..."}

The response has a status line (the protocol version, the status code, and a reason phrase), headers, and a body.

HTTP Methods and Their Semantics

HTTP/1.1 defines several methods, each with specific semantics:

• GET retrieves a resource. A GET request should have no side effects. It shouldn't create or modify anything. It's safe and idempotent, meaning calling it multiple times has the same effect as calling it once.

• POST submits data to create a new resource or trigger an action. It's neither safe nor idempotent: calling POST twice typically creates two resources.

• PUT replaces a resource entirely with the provided data. It's idempotent: calling PUT twice with the same data has the same effect as calling it once.

• PATCH partially updates a resource. Only the fields provided are changed.

• DELETE removes a resource. It's idempotent: deleting something that doesn't exist is still considered successful.

• HEAD is identical to GET but the server only returns headers, not the body. It's used to check if a resource exists or has been modified without downloading the full content.

• OPTIONS asks the server what methods are allowed for a resource. It's used in CORS preflight requests.

Status Codes

HTTP status codes are three-digit numbers grouped into five categories:

1xx Informational — the server has received the request and is continuing to process it. These are rarely seen in practice outside of specific use cases like HTTP upgrade (used to establish WebSocket connections).

2xx Success — the request was received, understood, and accepted.

• 200 OK: standard success response

• 201 Created: a new resource was created

• 204 No Content: success but nothing to return (common for DELETE)

3xx Redirection — further action is required to complete the request.

• 301 Moved Permanently: the resource has a new URL forever

• 302 Found: temporary redirect

• 304 Not Modified: the cached version is still valid (used with ETags)

4xx Client Error — the request contains bad syntax or can't be fulfilled.

• 400 Bad Request: the request is malformed

• 401 Unauthorized: authentication is required (despite the name, it means unauthenticated)

• 403 Forbidden: authenticated but not authorized to access this resource

• 404 Not Found: the resource doesn't exist

• 422 Unprocessable Entity: the request is syntactically valid but semantically wrong (common for validation errors)

• 429 Too Many Requests: rate limit exceeded

5xx Server Error — the server failed to fulfill a valid request.

• 500 Internal Server Error: something went wrong on the server

• 502 Bad Gateway: the server received an invalid response from an upstream server

• 503 Service Unavailable: the server is temporarily unavailable

• 504 Gateway Timeout: the upstream server did not respond in time

Caching in HTTP/1.1

One of HTTP/1.1's most powerful features is its built-in caching model. Responses can include headers that tell clients and intermediate caches how long to store a response and when to revalidate it.

• Cache-Control: max-age=3600 tells the client to cache this response for one hour.

• Cache-Control: no-cache tells the client to always revalidate with the server before using a cached response.

• Cache-Control: no-store tells the client never to cache this response.

ETag is a fingerprint of the response content. When the client makes a subsequent request, it sends the ETag back in an If-None-Match header. If the content hasn't changed, the server responds with 304 Not Modified and no body, saving bandwidth.

Last-Modified works similarly: the client sends If-Modified-Since and the server confirms whether the content has changed.

Caching is one of the key reasons REST over HTTP became dominant. GET requests to well-designed REST APIs can be cached at the CDN level, meaning the same response is served to thousands of users without the request ever reaching your origin server.

The Problems HTTP/1.1 Could Not Solve

HTTP/1.1 served the web well for two decades. But as the web grew more complex, applications more dynamic, and user expectations higher, its architectural limitations became significant performance bottlenecks.

Head-of-Line Blocking

HTTP/1.1 processes requests sequentially on a single connection. The server must finish responding to one request before the next one on the same connection begins.

Connection 1:
Request 1 (slow database query) -----> [3 seconds] -----> Response 1
Request 2 (fast in-memory read) -----> [waits 3 seconds] -----> Response 2
Request 3 (static file) -----------> [waits 3+ seconds] -----> Response 3

Request 2 and Request 3 are fast operations. But they're stuck waiting for Request 1 to complete. This is head-of-line blocking: the head of the queue blocks everything behind it.

Browsers worked around this by opening multiple parallel TCP connections to the same server, typically six. But each connection requires its own TCP handshake and TLS negotiation, consuming resources on both the client and server.

Verbose Headers on Every Request

Every HTTP/1.1 request sends its complete headers as plain text. Consider a mobile application making fifty requests during a session. On every single request, the following headers are sent in full:

Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c3JfMTIzIn0...
Content-Type: application/json
Accept: application/json
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate, br
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)...

The Authorization header alone, carrying a JWT, can be 400 to 600 bytes. Multiplied by fifty requests, that is 20 to 30 kilobytes of data carrying nothing but headers that haven't changed between requests.

On a 4G mobile connection with limited bandwidth, this is waste. On a 2G connection in a network-constrained environment, it's a significant performance penalty.

No Server Push

HTTP/1.1 is strictly request-response. The server can't send data until the client asks for it. This fundamental limitation means the server can never proactively inform the client of changes.

For applications requiring real-time updates, short polling became a common workaround: the client sends a request every few seconds asking "has anything changed?" This is inefficient because most polling requests receive a "no, nothing has changed" response, consuming bandwidth and server resources for no purpose.

Long polling was a refinement: the client sends a request and the server holds it open until something changes or a timeout occurs. This reduces unnecessary responses but keeps connections open indefinitely, consuming server resources.

Both are workarounds for a fundamental limitation of HTTP/1.1's request-response model.

Inefficient Use of Connections

Opening a new TCP connection requires the three-way handshake plus the TLS handshake: a process that can take 200 to 500 milliseconds on a mobile connection.

HTTP/1.1 introduced keep-alive connections to reuse connections across multiple requests, but head-of-line blocking made this only partially effective. Browsers opened multiple connections to compensate, but six parallel connections per domain is both a client limitation and a server resource concern at scale.

HTTP/2: Rebuilding the Foundation

Google published a protocol called SPDY (pronounced "speedy") in 2009, designed to address HTTP/1.1's performance limitations. SPDY demonstrated that significant improvements were possible without changing the fundamental HTTP semantics. HTTP/2, standardized by the IETF in 2015, was heavily based on SPDY and became the successor to HTTP/1.1.

HTTP/2 doesn't change what you send. From the application developer's perspective, requests still have methods, paths, headers, and bodies. Responses still have status codes, headers, and bodies. What HTTP/2 changes is how all of this is transmitted.

Binary Framing: The Core Change

HTTP/1.1 is a text protocol. Headers, status lines, and method names are all ASCII text. Machines must parse this text character by character to interpret it.

HTTP/2 is a binary protocol. Every piece of information is encoded as binary frames rather than text. Binary is more compact and significantly faster for machines to parse. Instead of tokenizing a string looking for colons and newlines to separate header names from values, a binary parser reads fixed-length fields directly from memory.

The binary framing layer is the foundation everything else in HTTP/2 is built upon.

Multiplexing: Many Streams, One Connection

HTTP/2 introduces the concept of streams. A stream is an independent, bidirectional sequence of frames within a single TCP connection. Multiple streams can exist simultaneously on the same connection.

Single TCP connection to api.example.com

Stream 1: GET /user/profile ---------> Response arrives
Stream 2: GET /user/balance ---------> Response arrives
Stream 3: POST /transactions --------> Response arrives
Stream 4: GET /notifications --------> Response arrives

All four streams active simultaneously
No stream waits for any other stream

This is multiplexing: many independent requests and responses interleaved on the same connection. Head-of-line blocking at the HTTP level is eliminated. A slow request on Stream 1 doesn't prevent Stream 2, 3, or 4 from receiving their responses.

One connection replaces six parallel connections. The TCP handshake and TLS negotiation happen once. Connection overhead drops dramatically.

Header Compression with HPACK

HTTP/2 compresses headers using an algorithm called HPACK specifically designed for HTTP headers.

HPACK works in two ways. First, it maintains a table of previously seen headers. Instead of retransmitting a header that was sent on the previous request, it sends a reference to the table entry: a single integer instead of hundreds of bytes of text.

Second, HPACK uses Huffman encoding for new header values, reducing the size of strings that can't be referenced from the table.

The result: a mobile application sending the same Authorization header on every request transmits it in full on the first request, then sends a one-byte or two-byte reference on every subsequent request. What was 500 bytes of overhead becomes 2 bytes.

Across fifty requests in a session, this eliminates thousands of bytes of redundant header transmission.

Stream Prioritization

HTTP/2 allows clients to assign priority to streams. A browser loading a web page can signal that the CSS file (needed to render anything) is higher priority than the analytics script (not needed for initial render). The server can use these priorities to decide the order in which it sends frames when multiple streams are active.

In practice, stream prioritization has been inconsistently implemented and is being redesigned in HTTP/3.

Server Push

HTTP/2 allows the server to proactively send resources to the client without waiting for a request. When a browser requests an HTML file, the server can immediately push the CSS and JavaScript files it knows the browser will need next, before the browser has even parsed the HTML to discover it needs them.

Client: GET /index.html
Server: Here is index.html
Server: (push) Here is styles.css — you will need this
Server: (push) Here is app.js — you will need this too

In practice, server push has had mixed adoption due to implementation complexity and the risk of pushing resources the client already has cached. HTTP/3 is reconsidering how push should work.

HTTP/2 and gRPC

HTTP/2's multiplexing and persistent connections make it the ideal transport for gRPC. A single HTTP/2 connection can carry many concurrent gRPC calls, including long-running streaming calls that push data continuously. This is why gRPC requires HTTP/2: the features that make gRPC efficient are provided by the transport layer.

HTTP/3 and QUIC: The Next Evolution

Even with HTTP/2's improvements, one fundamental problem remained: TCP head-of-line blocking.

HTTP/2 eliminated head-of-line blocking at the HTTP level. Multiple HTTP/2 streams can proceed independently. But all of those streams share a single TCP connection. TCP guarantees ordered delivery of all bytes in a connection. If a single TCP packet is lost, the entire connection stalls while TCP retransmits that packet, even for streams that have nothing to do with the lost packet.

HTTP/2 over TCP — packet loss scenario:

Stream 1: data in flight...
Stream 2: data in flight...
Stream 3: packet LOST — TCP retransmission required

Stream 1: STALLED (waiting for TCP retransmission)
Stream 2: STALLED (waiting for TCP retransmission)
Stream 3: retransmission in progress...

Both streams 1 and 2 are blocked by a packet loss that affected only stream 3. This is TCP head-of-line blocking, and HTTP/2 can't eliminate it because it operates above the TCP layer.

QUIC: A New Transport Protocol

Google developed QUIC (Quick UDP Internet Connections) to solve this problem. QUIC is a new transport protocol built on UDP instead of TCP, designed to provide some very helpful new features:

1. Multiplexing without head-of-line blocking: QUIC understands streams natively. A packet loss in one QUIC stream only stalls that stream. Other streams on the same connection continue flowing freely.

2. Built-in encryption: Unlike TLS which runs on top of TCP, QUIC has TLS 1.3 built into the protocol itself. The transport and security layers are integrated, reducing the number of round trips required before data can flow.

3. Faster connection establishment: A new QUIC connection requires one round trip before data can flow. For returning connections where a session ticket exists, QUIC can send data in zero round trips (0-RTT).

4. Connection migration: A TCP connection is identified by the four-tuple of source IP, source port, destination IP, and destination port. If any of these change (say, a mobile device switches from WiFi to cellular), the TCP connection breaks and must be re-established. QUIC connections are identified by a connection ID that survives network changes, enabling seamless handoff.

HTTP/3

HTTP/3 is HTTP semantics over QUIC. The request and response model remains the same. Headers, status codes, and methods are all identical. The transport underneath is QUIC instead of TCP.

HTTP/3 is particularly impactful for:

1. Mobile networks where packet loss is more common and devices frequently switch between networks.

2. High-latency connections where the reduced handshake round trips save meaningful time.

3. Applications with many concurrent streams where TCP head-of-line blocking was a real bottleneck.

As of 2026, HTTP/3 is supported by major browsers, CDNs, and an increasing number of backend servers. Adoption continues to grow.

Data Formats: How Information Is Encoded

Independent of which protocol carries data, systems need to agree on how data is encoded. The most important formats for API communication are JSON and Protocol Buffers.

JSON: The Universal Language

JSON (JavaScript Object Notation) was derived from JavaScript syntax and formalized as a standalone data format. Its design philosophy is human readability and simplicity.

A JSON object is a collection of key-value pairs enclosed in curly braces. Keys are always strings. Values can be strings, numbers, booleans, null, arrays, or other objects.

{
  "id": "usr_001",
  "name": "John Smith",
  "age": 28,
  "is_verified": true,
  "scores": [98, 87, 92],
  "address": {
    "city": "Lagos",
    "country": "Nigeria"
  }
}

JSON became the dominant API data format for several reasons. It's human-readable: a developer can look at a JSON response in a browser's developer tools and immediately understand it. It maps naturally to data structures in virtually every programming language. It requires no special tooling or schema definition. And it's flexible: fields can be added or removed without necessarily breaking existing clients.

The Structural Cost of JSON

JSON's human-readable design comes with a structural cost that becomes significant at scale.

Every field name is a string that travels over the network on every single response. In the example above, the strings "is_verified", "address", "country" aren't data. They're labels for data. They consume bytes, they must be tokenized and parsed, and they're repeated on every response for every user.

JSON is a text format, which means it must be parsed from text into the application's native data structures. This parsing isn't free: it requires allocating memory for strings, walking the text byte by byte to find delimiters, and constructing objects from the parsed values.

For a fintech platform with an internal API that returns a 1000-field response and is called by dozens of internal services millions of times per day, the cumulative cost of JSON's verbosity and parsing overhead becomes measurable in bandwidth bills and server CPU time.

JSON also has no formal schema at the network level. There's nothing in the JSON format itself that prevents a backend from changing "account_balance" to "balance". The change compiles fine. The server deploys. Clients that depend on "account_balance" break silently at runtime.

XML: The Predecessor

Before JSON, XML (eXtensible Markup Language) was the dominant data format for web services (used in SOAP, the predecessor to REST). XML is more verbose than JSON, wrapping every value in opening and closing tags:

<user>
  <id>usr_001</id>
  <name>John Smith</name>
  <age>28</age>
  <is_verified>true</is_verified>
</user>

XML has advantages: it supports schemas (XSD), namespaces, and complex document structures. It's still used in enterprise systems, document formats (DOCX, SVG, RSS), and configuration files. But for API communication, JSON's simplicity won.

REST: The Architecture That Took Over the World

REST (Representational State Transfer) was defined by Roy Fielding in his doctoral dissertation in 2000. Fielding was one of the principal authors of the HTTP specification, and REST emerged from his analysis of what made HTTP architecturally successful.

REST isn't a protocol. It's an architectural style: a set of constraints that, when applied to a distributed system, produce desired properties including scalability, simplicity, and modifiability.

The Six REST Constraints

Fielding defined six constraints that define a RESTful architecture. Most APIs described as "REST" implement a subset of these, which is why the term "RESTful" covers a wide spectrum.

1. Client-Server: The client and server are separate concerns. The client manages the user interface. The server manages data storage and business logic. They evolve independently. This separation allows each to scale and change without affecting the other.

2. Stateless: Each request from the client to the server must contain all the information needed to understand and process the request. The server doesn't store any session state between requests. If a client needs to be authenticated, the authentication information (typically a token) travels with every request.

Statelessness is what makes REST APIs horizontally scalable. Any server instance can handle any request because no session state needs to be co-located with the request. Load balancers can route requests freely.

3. Cacheable: Responses must define themselves as cacheable or non-cacheable. If a response is cacheable, clients and intermediate layers (CDN, reverse proxies) can store and reuse the response without hitting the server.

Caching is one of the most powerful properties of REST. A well-designed REST API can serve millions of identical GET requests from CDN cache, with only a fraction ever reaching the origin server.

4. Uniform Interface: The interface between client and server is standardized. Resources are identified by URIs. Resources are manipulated through representations. Messages are self-descriptive. This uniformity is what makes REST APIs universally accessible: a developer in any language can call a REST API using standard HTTP tooling.

5. Layered System: The client doesn't need to know whether it's connected directly to the server or to an intermediary (load balancer, CDN, API gateway, caching proxy). Each layer only sees the layer it is interacting with. This enables transparent scaling and security.

6. Code on Demand (Optional): Servers can extend client functionality by sending executable code (JavaScript). This is the only optional constraint and is the basis for how browsers work, but rarely relevant to API design.

Resources and URIs

The central concept in REST is the resource. A resource is any piece of information that can be named, like a user, an order, a product, or a collection of transactions.

Resources are identified by URIs (Uniform Resource Identifiers). The URI identifies what the resource is, not what to do with it. The HTTP method expresses the operation.

GET    /users           — retrieve all users
GET    /users/123       — retrieve user 123
POST   /users           — create a new user
PUT    /users/123       — replace user 123 entirely
PATCH  /users/123       — partially update user 123
DELETE /users/123       — delete user 123

GET    /users/123/orders        — orders belonging to user 123
POST   /users/123/orders        — create an order for user 123
GET    /users/123/orders/456    — order 456 belonging to user 123

The URI structure forms a hierarchy that reflects the relationships between resources. This makes APIs predictable: a developer who understands the resource model can guess the correct URIs.

Why REST Won

REST became the dominant architectural style for web APIs for reasons that go beyond technical merit:

Universal accessibility: Any device, any language, any framework that can make an HTTP request can call a REST API. There's no special client library needed.

HTTP alignment: REST leverages HTTP's existing infrastructure. CDN caching works for free. Load balancers understand HTTP. Monitoring tools speak HTTP. The entire ecosystem is built around HTTP semantics.

Simplicity: A REST API can be designed, documented, and consumed with minimal tooling. A developer can test endpoints in a browser or with curl immediately.

Developer experience: JSON over HTTP is something every web developer already understands. The learning curve is essentially zero.

Ecosystem maturity: OpenAPI/Swagger provides standardized documentation. Postman provides testing. Every programming language has robust HTTP client libraries.

The Limits of REST

REST's success is real. But so are its limitations, and understanding them is essential to knowing when to reach for something else.

Overfetching: Getting More Than You Need

A REST endpoint returns a fixed shape of data. The /users/123 endpoint returns the full user object: name, email, phone, address, preferences, account status, and thirty other fields.

A mobile screen that displays only the user's name and avatar must receive all of those fields to use two of them. The rest is waste: wasted bandwidth, serialization on the server, and deserialization on the client.

On a constrained mobile connection, this overfetching isn't just inefficient. It's a measurable degradation of user experience.

Underfetching: Not Getting Enough at Once

The opposite problem is equally common. A screen needs data from multiple resources: the user's profile, their recent orders, their notification count, and their account balance.

A REST API typically models these as separate endpoints. Loading this screen requires four separate HTTP requests, each with its own round-trip latency.

GET /users/123         → profile data
GET /users/123/orders  → orders data
GET /notifications?user=123 → notification count
GET /accounts/123/balance   → balance data

Four sequential round trips. On a 200ms latency connection, that's 800ms of network time before the screen can render completely.

The N+1 Problem

A common variant of underfetching: you fetch a list of resources, then must fetch additional data for each item in the list.

GET /orders            → returns 20 orders (each with a user_id)
GET /users/1           → user for order 1
GET /users/2           → user for order 2
...
GET /users/20          → user for order 20

21 requests to load one screen. This pattern appears constantly in REST APIs and is addressed in various ways: including nested data in responses, adding query parameters to expand related resources, or creating purpose-built endpoints for specific screens.

All of these workarounds create tension: the API becomes less general as it's optimized for specific client needs.

No Native Real-Time Support

REST is request-response. The client initiates every interaction. The server can never proactively push data.

Real-time features like live notifications, collaborative editing, and streaming data require either polling (inefficient), long-polling (complex), or a separate real-time technology bolted alongside the REST API.

The Documentation Drift Problem

A REST API contract lives in documentation. Nothing in the HTTP protocol enforces that the documentation accurately reflects the API's actual behavior. As APIs evolve, documentation falls behind. Fields are renamed, types change, endpoints are deprecated. Clients built against outdated documentation break.

This isn't a theoretical problem. It's a daily reality in engineering teams where the backend and frontend evolve at different speeds.

GraphQL: Letting the Client Decide

GraphQL was developed at Facebook starting in 2012 and open-sourced in 2015. Facebook built it to solve a specific problem: their mobile app needed to fetch complex, interconnected social data from a REST API, and the resulting overfetching and multiple round trips were degrading performance on mobile devices.

GraphQL's core insight is simple and radical: instead of the server deciding what data to return, let the client specify exactly what it needs.

The Query Language

GraphQL is both a query language for APIs and a runtime for executing those queries. Rather than calling different endpoints for different data, all GraphQL requests go to a single endpoint (typically /graphql) and include a query that describes precisely what data is needed.

A GraphQL query for a user profile screen:

query UserProfile {
  user(id: "usr_123") {
    name
    avatarUrl
    recentOrders(limit: 3) {
      id
      total
      status
      createdAt
    }
    notificationCount
  }
}

The response contains exactly and only the fields requested. Nothing more. If the client needs only name and avatarUrl, it requests only those two fields. The response contains only two fields.

Mutations and Subscriptions

GraphQL has three operation types:

1. Queries fetch data. They're the GraphQL equivalent of GET requests.

2. Mutations modify data: creating, updating, or deleting resources. They're the GraphQL equivalent of POST, PUT, PATCH, and DELETE.

3. Subscriptions establish a persistent connection and push data in real-time when specified events occur. A subscription to orderStatusChanged receives a push every time any order's status changes. This is GraphQL's real-time capability, typically implemented over WebSockets.

The Schema

Every GraphQL API is defined by a schema written in the Schema Definition Language (SDL). The schema declares every type, query, mutation, and subscription the API supports.

type User {
  id: ID!
  name: String!
  email: String!
  orders: [Order!]!
  notificationCount: Int!
}

type Order {
  id: ID!
  total: Float!
  status: OrderStatus!
  createdAt: String!
}

enum OrderStatus {
  PENDING
  PROCESSING
  SHIPPED
  DELIVERED
}

type Query {
  user(id: ID!): User
  orders(userId: ID!, limit: Int): [Order!]!
}

type Mutation {
  createOrder(userId: ID!, items: [OrderItemInput!]!): Order!
}

The schema is introspectable: clients can query the schema itself to discover what types and operations are available. This enables powerful tooling: GraphQL IDEs can autocomplete queries, validate them against the schema before sending, and display documentation inline.

Where GraphQL Wins

Precise data fetching: Clients request exactly what they need. Overfetching is eliminated by design.

Single round trip for complex data: Data from multiple resources is fetched in a single request. The N+1 problem is solved at the query level rather than requiring the client to make multiple requests.

Strongly typed schema: The schema is the contract. Clients can validate their queries against it at build time. Type mismatches are caught before deployment.

Frontend agility: Frontend teams can evolve their data requirements without asking backend teams to create new endpoints. New screens, data combinations, and features are all handled by writing a new query.

Excellent tooling: GraphiQL and Apollo Studio provide interactive schema exploration, query building, and performance analysis.

Where GraphQL Struggles

Query complexity: A malicious or poorly written query can request enormous amounts of nested data. A query that fetches every user, each user's orders, each order's items, and each item's product details can bring a server to its knees.

REST endpoints can be individually optimized. GraphQL requires query complexity analysis, depth limiting, and rate limiting to protect the server.

Caching is harder: REST GET requests are cacheable at the HTTP level by default. GraphQL queries all go through POST requests to a single endpoint, breaking standard HTTP caching. Clients must implement their own caching (Apollo Client does this), but CDN-level caching is essentially unavailable for dynamic queries.

Over-engineering simple APIs: If your API is straightforward CRUD operations with no complex data relationships and no mobile clients with aggressive data constraints, GraphQL's added setup cost exceeds its benefit.

Real-time at scale is complex: GraphQL subscriptions work, but scaling WebSocket connections for thousands of concurrent subscribers is infrastructure-intensive and requires careful architecture.

Error handling is non-standard: A GraphQL request can partially succeed: some fields resolve successfully while others fail. The response includes both data and errors simultaneously. Handling this gracefully requires more nuanced error handling logic than a simple HTTP status code.

WebSockets: When HTTP Is Not Enough

HTTP, in all its versions, is fundamentally request-response. The client speaks first. The server responds. The conversation ends. Even with HTTP/2's server push, the client initiates every new exchange.

But some applications genuinely need both sides to be able to speak at any moment, without waiting for the other to ask first. For example, a chat application where both parties send messages freely. A live collaborative document where every keystroke is broadcast to co-editors. An online game where the server pushes state updates as they happen and the client sends actions continuously.

For these cases, WebSockets provide a fundamentally different communication model.

The WebSocket Handshake

A WebSocket connection starts as an HTTP request and then upgrades to a WebSocket connection. This upgrade mechanism means WebSockets work through existing HTTP infrastructure (firewalls, proxies, load balancers) without requiring special configuration.

The upgrade request:

GET /chat HTTP/1.1
Host: api.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

The server confirms the upgrade:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Status code 101 means "Switching Protocols." From this point forward, the HTTP connection is replaced by a WebSocket connection. The protocol has changed. HTTP headers, status codes, and methods no longer apply.

Full-Duplex, Persistent Communication

The WebSocket connection is:

• Full-duplex: both the client and server can send messages at any time, simultaneously, without waiting for the other to finish.

• Persistent: the connection stays open until explicitly closed by either party or until a network interruption occurs.

• Low overhead: once established, WebSocket messages have minimal framing overhead compared to HTTP. A small WebSocket message may have only 2 to 10 bytes of overhead, versus potentially hundreds of bytes of HTTP headers.

WebSocket connection open

Client: "Hello, I'm user 123"
Server: "Welcome, user 123"
Server: "User 456 just sent you a message: Hey!"
Client: "Thanks, here's my reply: Hi there!"
Server: "New notification: your payment was confirmed"
Client: "Great, show me my balance"
Server: "Your balance is NGN 500,000"
Server: "Another notification: transfer from user 789 received"

[Both sides communicate freely, at any time, simultaneously]

Where WebSockets Win

True real-time bidirectional communication: Applications where both client and server need to send messages at unpredictable times and at high frequency. For example, chat, live collaboration, multiplayer games, financial trading terminals.

Low-latency messaging: Once the connection is established, message round-trip times can be in the single-digit milliseconds, limited only by network latency rather than connection setup overhead.

Native browser support: The WebSocket API is built into every modern browser. No libraries are needed for the fundamental connection.

Event-driven architecture on the client: WebSocket events (message, close, error) map naturally to event-driven client code.

Where WebSockets Struggle

Stateful connections: Each WebSocket connection must be maintained by a specific server instance. When scaling horizontally, a client connected to Server A can't receive messages from Server B without a shared pub/sub layer (like Redis) that all server instances publish to and subscribe from. This adds infrastructure complexity.

No built-in request-response correlation: WebSockets are a message stream. If you send a message and expect a response, there's no built-in mechanism to correlate which response corresponds to which request. You have to build this yourself.

No schema or contract: WebSockets send raw text or binary. The format of messages is defined entirely by the application. Two systems communicating over WebSockets must agree on message format out of band, in documentation, and there's nothing to enforce it at the connection level.

Firewall and proxy complications: Some corporate networks and older proxies don't support the HTTP upgrade mechanism correctly, breaking WebSocket connections. This is less common than it was but still occurs in enterprise environments.

Reconnection must be handled manually: WebSocket connections can drop due to network instability. Applications must implement reconnection logic, including managing state across reconnections.

Server-Sent Events: The Simpler Real-Time Option

Between REST's pure request-response and WebSocket's full bidirectional communication lies a middle option that most developers overlook: Server-Sent Events (SSE).

SSE establishes a one-directional persistent connection: the server pushes data to the client over a regular HTTP connection, and the client listens. The client can't send data back through the same connection.

How SSE Works

The client makes a standard HTTP GET request with an Accept: text/event-stream header:

GET /notifications HTTP/1.1
Host: api.example.com
Accept: text/event-stream
Authorization: Bearer token123

The server responds with a 200 OK and keeps the connection open, periodically sending events:

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache

data: {"type": "balance_update", "balance": 500000}

data: {"type": "transaction", "id": "txn_001", "amount": -5000}

event: notification
data: {"message": "Your transfer has been confirmed"}

id: 42
data: {"type": "order_status", "status": "shipped"}

Each event is separated by a blank line. Events can include a data field, an optional event type, and an optional id for resumability.

Automatic Reconnection

One of SSE's most practical features is automatic reconnection. If the connection drops, the browser automatically reconnects, sending the last received event ID in a Last-Event-ID header. The server can resume from that point, ensuring no events are missed.

Where SSE Wins

Simplicity: SSE works over plain HTTP. There's no protocol upgrade needed, and no special infrastructure. It works through every HTTP/2 connection, load balancer, and CDN that supports streaming.

Native browser support: The EventSource API is built into every modern browser. Automatic reconnection is built in.

Perfect for one-directional feeds: Live dashboards, notification streams, news feeds, real-time analytics, server logs: any scenario where the server pushes a continuous stream of updates and the client only reads.

HTTP/2 multiplexing: Over HTTP/2, multiple SSE connections can share a single TCP connection. The browser connection limit that affected SSE over HTTP/1.1 doesn't apply.

Natural fit for existing infrastructure: SSE responses are just HTTP responses. Existing load balancers, authentication middleware, and monitoring tools work without modification.

Where SSE Struggles

One direction only: The client can't send data back through the SSE connection. For bidirectional scenarios, SSE isn't sufficient on its own.

Text only (natively): SSE events are text. Binary data must be base64-encoded, adding overhead.

No native support in all environments. SSE is a browser API. In other environments (mobile apps, server-to-server), it requires an HTTP client configured to handle streaming responses.

SSE vs WebSockets: The Decision

Choose SSE when the server pushes data and the client only reads: notifications, live feeds, dashboards, or streaming responses from an AI model. SSE is simpler, works over plain HTTP, and has automatic reconnection built in.

Choose WebSockets when both the client and server need to send messages freely and simultaneously: chat, collaborative editing, and games. The added complexity of WebSockets is justified when you genuinely need bidirectional communication.

Protocol Buffers: A New Language for Data

Protocol Buffers (protobuf) is a binary serialization format developed by Google. Where JSON encodes data as human-readable text, protobuf encodes data as compact binary. This single difference has cascading implications for payload size, parsing speed, type safety, and schema enforcement.

The Schema-First Approach

Unlike JSON, where you simply start writing key-value pairs, protobuf requires defining a schema first. You describe your data structures in a .proto file using Protocol Buffer Language, a language-agnostic schema definition language.

The schema definition:

syntax = "proto3";

message User {
  string id = 1;
  string name = 2;
  string email = 3;
  double balance = 4;
  bool is_verified = 5;
  int32 kyc_level = 6;
}

message Order {
  string id = 1;
  string user_id = 2;
  double total = 3;
  string status = 4;
  int64 created_at = 5;
}

Each field has a name and a type, as in any structured data format. But it also has a field number: the small integer after the equals sign. This field number is the key to protobuf's efficiency.

Binary Encoding: Why Field Numbers Matter

When protobuf encodes data to binary, field names don't appear in the output. Instead, only the field number and the encoded value are written. Field 1 (id) becomes a tag byte indicating "field 1, type string" followed by the string's length and bytes. Field 4 (balance) becomes a tag byte indicating "field 4, type 64-bit float" followed by eight bytes of IEEE 754 double-precision float.

No "id": string, "balance": string, quotation marks, colons, or braces. Just field tags and values in a compact binary stream.

The same user object that occupies approximately 100 bytes in JSON occupies approximately 35 bytes in protobuf. For a 1000-field enterprise API response called millions of times per day, this difference translates directly to reduced bandwidth consumption and infrastructure cost.

Parsing binary is also fundamentally faster than parsing text. A binary parser reads a fixed-length tag, determines the type and length of the following value, reads that value, and moves to the next field. A JSON parser must tokenize a text stream character by character, handle escape sequences, infer types from value format, and construct a dynamic object from parsed key-value pairs.

On constrained devices or in high-throughput server-to-server communication, this parsing speed difference is meaningful.

Code Generation: The Contract Comes Alive

The .proto schema file is the input to the protoc compiler. This compiler generates data classes in any supported language from the same schema definition.

The same user.proto file generates:

• A User class in Go for the backend server

• A User class in Dart for the Flutter client

• A User class in Python for the data processing service

• A User class in TypeScript for the web frontend

Every generated class has typed fields, serialization/deserialization methods, and equality comparison. There's no manual JSON parsing, type casting, or risk of field name typos. The compiler guarantees that every language's representation of a User is identical.

When the schema changes — a new field is added or a field is removed, for example — every team regenerates their classes. If the change is breaking (a required field removed or a type changed in an incompatible way), the compiler reports errors in every affected codebase. The problem is caught before any code reaches production.

Schema Evolution Rules

Protobuf's field number system enables backward-compatible schema evolution. Because fields are identified by number rather than name, the following changes are safe:

• Adding a new field with a new number is always safe. Existing clients ignore fields they don't recognize. New clients receive the new field.

• Removing a field by marking it as reserved is safe. Existing encoded data that contains the removed field is simply ignored when decoded. The field number must be marked reserved to prevent its reuse.

• Renaming a field is safe. Names aren't encoded. Only the number matters at the binary level.

• Changing a field's type in incompatible ways is unsafe and breaks existing encoded data.

This evolution model means protobuf schemas can grow over time without coordinated updates across all clients and servers.

Trade-offs

Protobuf's efficiency comes with costs that make it inappropriate for all contexts.

Binary data isn't human-readable. You can't open a protobuf response in a browser's developer tools and see what it contains. Debugging requires either decoding the binary with the schema or using specialized tools.

Protobuf also requires tooling. Every consumer of a protobuf-encoded API needs the schema and a protobuf library to decode it. For public APIs consumed by unknown third parties, this is a significant barrier. JSON requires nothing: every programming environment can parse it with built-in libraries.

Schema changes require coordination. When a schema changes, every consumer must update. For internal systems where you control all consumers, this is manageable. For public APIs, it requires versioning and migration strategies.

gRPC: Remote Procedure Calls at Scale

gRPC combines Protocol Buffers with HTTP/2 and Remote Procedure Call semantics to produce a framework for service-to-service communication that is faster, more structured, and more powerful than REST for specific use cases.

Remote Procedure Calls: The Core Concept

A Remote Procedure Call (RPC) framework makes calling a function on a remote server feel like calling a local function. Instead of constructing an HTTP request, serializing a body, parsing a response, and handling status codes, you call a function with typed arguments and receive a typed return value. The network communication is abstracted away.

// Without RPC (manual REST)
const response = await http.post('/users', headers: {...}, body: json.encode(data));
const user = User.fromJson(json.decode(response.body));

// With RPC (gRPC)
final user = await userService.createUser(CreateUserRequest(name: "John", email: "john@example.com"));

The second form is simpler, type-safe, and requires no knowledge of HTTP methods, endpoints, or serialization formats.

The Four Communication Patterns

gRPC's most significant advantage over REST is its support for four distinct communication patterns, all defined in the same .proto schema and accessible through the same generated client.

Unary RPC is the familiar request-response pattern. One request and one response. It's equivalent to a REST API call.

Client ——— LoginRequest ——→ Server
Client ←—— LoginResponse —— Server

Server Streaming RPC sends one request and receives a continuous stream of responses. The server pushes messages as they become available without the client needing to request each one.

Client ——— WatchBalanceRequest ——→ Server
Client ←— BalanceResponse ———————— Server (balance: 500,000)
Client ←— BalanceResponse ———————— Server (balance: 495,000)
Client ←— BalanceResponse ———————— Server (balance: 1,000,000)
[Stream stays open, server pushes on every change]

Client Streaming RPC sends a stream of messages to the server and receives one response at the end. The server processes all received messages and responds once.

Client ——— DocumentChunk 1 ——→ Server
Client ——— DocumentChunk 2 ——→ Server
Client ——— DocumentChunk 3 ——→ Server
Client ←————— UploadResponse —— Server (all chunks processed)

Bidirectional Streaming RPC allows both client and server to send streams of messages simultaneously, in any order.

Client ——— ChatMessage ——→ Server
Server ←— ChatMessage ——— Client
Client ——— ChatMessage ——→ Server
Server ←— ChatMessage ——— Client  (server-initiated)
[Both sides communicate freely and simultaneously]

Why HTTP/2 and Protobuf Make gRPC Efficient

gRPC's efficiency comes from the combination of its two underlying technologies working together.

HTTP/2's multiplexed persistent connections mean many concurrent gRPC calls, including long-running streaming calls, share a single connection. There's no connection setup overhead per call. Multiple streams proceed in parallel without blocking each other.

Protocol Buffer's binary encoding means payloads are compact and parsing is fast. A high-frequency service-to-service call that would transmit 100 bytes of JSON transmits 35 bytes of protobuf. At thousands of calls per second between microservices, this difference is significant.

The generated clients eliminate all serialization and deserialization code. The schema enforces that client and server agree on the contract. Breaking changes are caught by the compiler.

The Organizational Contract

In organizations using gRPC at scale, .proto files live in a dedicated repository separate from any individual service. This repository is the single source of truth for every service contract.

When an engineer wants to add a new field to an API, they open a pull request in the proto repository. Engineers from every affected team review it. The change is discussed, refined, and approved before any implementation begins. When it merges, every team regenerates their clients. Changes that break existing behavior are caught in code review, not in production.

This governance model transforms API evolution from a coordination problem into a code review process.

gRPC's Limitations

gRPC doesn't work natively in web browsers. Browsers can't directly make HTTP/2 requests with the necessary control required for gRPC. A proxy layer (gRPC-Web) is required to translate between gRPC-Web's browser-compatible format and standard gRPC. This adds infrastructure complexity and limits gRPC's applicability for browser-based clients.

gRPC also requires HTTP/2. Environments that don't support HTTP/2 can't use gRPC.

Binary encoding makes debugging harder as well. Inspecting gRPC traffic requires specialized tools and access to the proto schema.

For public APIs consumed by third-party developers, gRPC's tooling requirements are a higher barrier than REST's universally accessible JSON over HTTP.

The Complete Comparison

How to Choose: The Engineering Decision Framework

No single communication approach is universally best. Each exists because it solves specific problems better than the alternatives. The engineering decision involves matching the tool to your requirements.

When to Use REST

Use REST when the API is public or consumed by third parties. REST's universal accessibility makes it the only reasonable choice for public APIs. Any developer in any language can call a REST API with standard HTTP tools. There are no schema files, generated clients, or special libraries.

REST is also a good fit when caching is a priority. REST GET responses can be cached at every layer: CDN, reverse proxy, and browser. For content that doesn't change frequently, REST with proper cache headers can serve millions of requests without hitting the origin server.

It's also solid when the operation is simple request-response. If you're building straightforward CRUD operations with no streaming requirements and no complex data relationships, REST is simpler to implement, document, and debug than any alternative.

And finally use REST when developer experience for the consumer matters. REST APIs are immediately accessible in a browser. They can be tested with curl. Every developer already understands them.

When to Use GraphQL

Use GraphQL when multiple client types have significantly different data needs. A mobile app that needs minimal data for a list view and richer data for a detail view, alongside a desktop app that needs comprehensive data, are ideal GraphQL consumers. Each queries exactly what it needs.

GraphQL also works well for complex interconnected data with many relationships. Social graphs, product catalogs with deeply nested attributes, or content management systems with rich content relationships: GraphQL's ability to traverse relationships in a single query is a genuine advantage.

It's also a good choice for frontend teams that need to iterate quickly. When the frontend can evolve its data requirements without backend changes, development velocity increases. New screens, new data combinations, no new endpoints needed.

And finally, GraphQL works well if you're comfortable with the operational complexity. GraphQL requires query complexity protection, custom caching strategies, and more sophisticated error handling. These are worth the effort when the data fetching advantages are real.

When to Use WebSockets

Use WebSockets when both the client and server need to send messages at any time. Genuine bidirectional real-time communication where either party can initiate a message at any moment.

WebSockets also work great for chat, collaboration, and games. Live chat applications, collaborative document editing, multiplayer real-time games are the canonical WebSocket use cases.

And WebSockets is a solid choice when low-latency messaging is critical. The minimal framing overhead and persistent connection make WebSockets the lowest-latency option for frequent message exchange.

When to Use Server-Sent Events

Use SSE when the server needs to push updates but the client only reads. Notification feeds, live dashboards, streaming AI responses, real-time analytics, or any scenario where the server has a continuous stream of data to deliver and the client only consumes.

SSE also works well when you value simplicity over full bidirectionality. SSE is significantly simpler to implement and operate than WebSockets for one-directional use cases. Automatic reconnection is built in. It works over plain HTTP.

When to Use gRPC

Use gRPC when multiple internal services share the same contract. When several teams build services that call each other, a .proto schema enforced by the compiler prevents contract drift. Everyone generates their clients from the same source of truth.

gRPC also works well for high-frequency service-to-service communication. Two microservices exchanging thousands of calls per second benefit from protobuf's compact binary encoding and HTTP/2's persistent multiplexed connections.

It's also a solid choice for large payloads that are consumed by many internal systems. An internal enterprise API with hundreds of fields called by dozens of internal applications benefits enormously from protobuf's size reduction. Less bandwidth, less parsing overhead, and compiled contract enforcement.

gRPC also works great when low-bandwidth networks matter. For mobile applications in markets where network conditions are variable or constrained, protobuf's binary encoding reduces payload size by 3 to 10 times compared to JSON. The difference between a 15 kilobyte response and a 3 kilobyte response is the difference between a 3-second load and a sub-second load on a 2G connection.

And finally, use gRPC when streaming is a core requirement and you want one framework. gRPC's four communication patterns (unary, server streaming, client streaming, and bidirectional) cover every scenario without requiring separate WebSocket infrastructure alongside your API.

The Hybrid Reality

Most sophisticated systems use multiple approaches, each where it genuinely wins:

A Large Engineering Organization

Public REST API
  External developers, partners, open integrations
  JSON over HTTPS. OpenAPI documentation.
  CDN caching for frequently accessed resources.

Internal gRPC Network
  Service-to-service communication
  Auth service, payment service, notification service,
  fraud detection: all communicating with typed contracts
  over efficient binary protobuf on HTTP/2.

Real-Time Layer
  WebSockets for bidirectional features (live chat, collaboration)
  SSE for one-directional feeds (notifications, live dashboards)
  gRPC streaming for real-time data with typed contracts

Mobile API
  REST for standard operations (profile, settings, history)
  gRPC for high-frequency or large payload calls
  SSE for notification streaming

There's no architectural purity requirement. Each layer uses what fits its requirements. The discipline is in making these choices deliberately rather than by habit or default.

Conclusion

The history of how clients and servers communicate is the history of engineers discovering the limitations of existing tools and building better ones.

HTTP/1.1 gave us a universal request-response protocol that built the web. Its text-based format and sequential connection model worked well for the web of the 1990s and 2000s. As applications became more complex and performance expectations rose, its limitations became bottlenecks.

HTTP/2 rebuilt the transport layer with binary framing and multiplexing, eliminating head-of-line blocking at the HTTP level, compressing headers, and enabling server push. HTTP/3 took this further by replacing TCP with QUIC, addressing the remaining head-of-line blocking at the transport level and making connection establishment faster.

JSON became the dominant data format because of its human readability and universal support. Protocol Buffers emerged as an alternative for contexts where JSON's verbosity and lack of schema enforcement create real problems: internal services, high-frequency communication, constrained networks, and teams needing compile-time contract enforcement.

REST codified HTTP's architectural strengths into a style that made APIs universally accessible and HTTP-native. Its success wasn't purely technical: it aligned with what developers already understood and what the HTTP ecosystem already supported. Its limitations in data fetching efficiency and real-time communication opened the door for GraphQL and streaming alternatives.

GraphQL solved REST's overfetching and underfetching problems by inverting control: the client specifies exactly what it needs. WebSockets solved REST's inability to support genuine bidirectional real-time communication. Server-Sent Events provided a simpler real-time option for one-directional streaming. gRPC combined Protocol Buffers, HTTP/2, and RPC semantics into a framework that excels at typed service-to-service communication at scale.

Understanding all of these tools, along with why each was built, what problem it solves, and where it struggles, is what enables you to make deliberate architectural decisions rather than defaulting to whatever is most familiar.

The right communication approach is always the one that fits the specific requirements of the system you're building: the clients consuming it, the data being exchanged, the network conditions it operates in, the teams building and maintaining it, and the operational complexity you are prepared to manage.

That clarity of fit is what engineering judgment looks like in practice.

Each method serves a specific purpose to keep web communication clear, secure, and organized.

In this article, we will break down the most common HTTPS methods and explain how they function to make online interactions work smoothly.

Table of Contents

1. GET Method

2. POST Method

3. PUT Method

4. PATCH Method

5. DELETE Method

6. HEAD Method

7. OPTIONS Method

8. TRACE Method

9. CONNECT Method

10. Conclusion

GET Method

The GET method is one of the most common HTTP methods and is used to request data from a server. Think of it as asking for information without changing anything.

When you visit a webpage, your browser sends a GET request to the server asking for the content of the page. The server then responds with the data (such as HTML, images, or other files) that the browser displays.

One important thing about GET is that it doesn't make any changes to the data. It simply "reads" or retrieves the information. For example, when you browse through social media or search for products online, the app or website uses GET to display data without altering it.

Another key point is that GET requests send parameters in the URL itself. This means any data you're asking for is visible in the browser's address bar. For example, if you're searching for a product on an online store, the search term is included in the URL.

Example of a GET Request

Here’s a simple example of a GET request in JavaScript using the Fetch API:

fetch('https://api.example.com/products?category=shoes')
  .then(response => response.json())
  .then(data => console.log(data))
  .catch(error => console.error('Error:', error));

In this example, the GET request is made to the URL https://api.example.com/products with a query parameter category=shoes, asking the server to return products in the shoes category.

Use Cases of the GET Method

GET is mainly used to fetch information, and there are many common scenarios where it's applied:

1. Loading a Webpage: Every time you type a URL into your browser or click a link, you're making a GET request. The browser asks the server for the webpage, and the server sends back the content to display.

   • Example: GET /index.html HTTP/1.1

2. Fetching Data from APIs: When developers build applications, they often use APIs (Application Programming Interfaces) to get data from external servers. For instance, a weather app uses a GET request to fetch the current temperature from a weather API.

   • Example:

    fetch('https://api.weather.com/current?city=Lagos')
       .then(response => response.json())
       .then(data => console.log(data));

3. Search Queries: When you search for something on Google or other search engines, a GET request is made. The search term you entered is included in the URL, and the server returns a list of matching results.

   • Example: GET /search?q=JavaScript

4. Retrieving Files: Whether you're downloading an image, viewing a PDF, or playing a video, GET is used to fetch those files from a server.

   • Example: GET /files/image.jpg

Best Practices for GET Requests

To use GET requests effectively, it's important to follow some good practices to ensure smooth and secure data handling:

1. Use GET Only for Retrieving Data: GET requests are meant to fetch data, not to send sensitive information like passwords or personal data. Since the parameters in a GET request are included in the URL, anyone can see them. For example, if you're logging into a website, you shouldn't use GET to send your password, because it would show up in the URL.

   • Example of what not to do:

    fetch('https://example.com/login?username=john&password=secret');

2. Keep URLs Short and Clean: Since GET requests include data in the URL, long URLs can become problematic. There is also a limit to how much data can be included in a GET request URL (depending on the browser and server), so avoid putting too much information there. If you need to send a lot of data, consider using a POST request instead.

3. Enable Caching for Performance: GET requests are often cached by browsers, meaning the browser can store the response and reuse it without contacting the server again. This improves performance, especially for static content that doesn’t change often, like images or style sheets. To take advantage of this, ensure your server sends proper cache-control headers, so frequently requested data can be loaded faster.

   • Example of setting cache headers:

    Cache-Control: max-age=3600

4. Avoid Making GET Requests for Actions That Change Data: Since GET is a "safe" method, it should only be used for actions that don't modify data. If you want to create, update, or delete data, use methods like POST, PUT, or DELETE. For instance, if you accidentally use GET to delete a resource, someone could remove it just by clicking a link or refreshing the page, which is not safe.

   • Example of not using GET for deletion:

    GET /delete/user/123

5. Be Cautious with Sensitive Data: Since GET requests are part of the URL, they can be logged or saved in a browser’s history. Avoid sending sensitive information like passwords, credit card details, or private data in a GET request. Always use methods like POST for handling such information, which keeps it hidden.

POST Method

The POST method is used to send data to a server. Unlike the GET method, which only retrieves data, POST allows you to submit information that the server can use to process or store. POST is commonly used in forms, where users input data such as usernames, passwords, or contact details.

When a POST request is made, the data is sent in the body of the request rather than in the URL. This makes POST ideal for sending larger or more sensitive information, such as passwords, because the data is hidden and doesn’t appear in the browser's address bar.

For example, when you sign up for a website or submit a comment on a blog, the POST method is used to send your information to the server, which processes it and stores it in a database.

Example of a POST Request

Here’s an example of a POST request using the Fetch API to send form data to a server:

const formData = {
  username: 'john_doe',
  password: 'mypassword123'
};

fetch('https://example.com/login', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify(formData)
})
.then(response => response.json())
.then(data => console.log('Success:', data))
.catch(error => console.error('Error:', error));

In this example, the POST request sends username and password as JSON data in the body of the request, making it a secure way to handle sensitive information like passwords.

Differences Between GET and POST

Although GET and POST are used to communicate with a server, they serve different purposes and handle data in different ways:

Data Transmission:

• GET: Data is included in the URL, making it visible in the address bar. This limits how much data can be sent.

• POST: Data is sent in the body of the request, which allows for sending larger amounts of information. This also keeps sensitive information hidden from the URL.

Purpose:

• GET: Used for retrieving data. It doesn’t change or modify anything on the server.

• POST: Used to send data that may change or add to the server's resources, such as adding a new user to a database or submitting a form.

Caching:

• GET: GET requests can be cached. This means that the browser may save the response, making future requests faster.

• POST: POST requests are not cached, as they often involve new or updated data that shouldn't be reused.

Idempotence:

• GET: Sending the same GET request multiple times doesn’t change the result. It will return the same data every time.

• POST: Sending the same POST request multiple times may result in different outcomes. For example, submitting a form twice could create duplicate entries.

Common Scenarios for Using POST

POST is ideal in situations where you need to send data to the server, often for processing or storage. Here are some common use cases:

1. Submitting Forms: Whenever you fill out and submit a form online, such as signing up for a newsletter or entering your details in a registration form, the POST method is used to send that information to the server. The server then processes the data, stores it, or performs another action based on it.

   • Example:

    <form action="https://example.com/register" method="POST">
      <input type="text" name="username" />
      <input type="password" name="password" />
      <button type="submit">Sign Up</button>
    </form>

2. User Authentication: When you log in to a website using a username and password, POST is often used to send your credentials securely to the server. The server checks the information and grants access to your account if the credentials match.

3. Uploading Files: POST is also used for uploading files, such as images, documents, or videos. Since the POST method allows sending large amounts of data, it’s perfect for uploading files that need to be processed or stored on the server.

   • Example using a form for file uploads:

    <form action="https://example.com/upload" method="POST" enctype="multipart/form-data">
      <input type="file" name="file" />
      <button type="submit">Upload File</button>
    </form>

4. Creating New Resources: POST is often used in APIs to create new resources. For example, when you add a new product to an online store, the POST method is used to send the product details to the server, which adds the product to the store's database.

   • Example of sending product data:

    const product = {
      name: 'New Sneakers',
      price: 59.99,
      category: 'Footwear'
    };

    fetch('https://example.com/api/products', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json'
      },
      body: JSON.stringify(product)
    })
    .then(response => response.json())
    .then(data => console.log('Product added:', data));

5. Sending Data to an API: POST is widely used in APIs when you need to send data that will be processed or stored. For example, an app that tracks your fitness progress may use POST to send your workout details to a server, where it’s stored and analyzed.

6. Making Purchases Online: When you make an online purchase, POST is used to send the payment details to the server for processing. The server processes the transaction and updates the system with your order information.

PUT Method

The PUT method is used to update or replace an existing resource on the server. It sends data to the server and tells it to create a new resource if none exists or replace the current one if it does. The key idea with PUT is that you are telling the server exactly what the resource should look like.

For example, imagine a user profile on a website. If you use PUT to update your profile, the server will replace the entire profile with the new data you provide. Every part of the profile will match exactly what you send, so if some details are missing, they will be overwritten with the new data.

Example of a PUT Request

Here’s an example of a PUT request using the Fetch API to update user data:

const updatedProfile = {
  username: 'john_doe_updated',
  email: 'john_updated@example.com',
  age: 30
};

fetch('https://example.com/users/123', {
  method: 'PUT',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify(updatedProfile)
})
.then(response => response.json())
.then(data => console.log('Updated:', data))
.catch(error => console.error('Error:', error));

In this example, the PUT request updates the user profile with new data. The profile will be replaced with username, email, and age values. If any data is missing, such as phoneNumber, it will be removed from the profile.

When to Use PUT

PUT is mainly used when you want to update or replace a resource with specific, complete data. Here are some common situations where PUT is appropriate:

1. Updating a Resource: When you need to make changes to an existing resource, PUT is used to send a new version of the entire resource. For example, updating a blog post, product details, or user information would require sending a complete replacement of the resource using PUT.

   • Example:

    const updatedPost = {
      title: 'New Title for My Blog',
      content: 'Updated blog content here...',
      author: 'John Doe'
    };

    fetch('https://example.com/blog/45', {
      method: 'PUT',
      headers: {
        'Content-Type': 'application/json'
      },
      body: JSON.stringify(updatedPost)
    });

2. Creating a Resource if None Exists: If you send a PUT request to a specific URL that doesn't have a resource yet, the server will create one using the data you provide. This is useful when you're working with resources that need to be fully defined upfront.

   • Example of creating a product if it doesn’t exist:

    const newProduct = {
      id: 101,
      name: 'New Sneakers',
      price: 59.99,
      category: 'Footwear'
    };

    fetch('https://example.com/products/101', {
      method: 'PUT',
      headers: {
        'Content-Type': 'application/json'
      },
      body: JSON.stringify(newProduct)
    });

3. Working with APIs: When interacting with APIs, PUT is often used when you need to make updates to a resource like a user profile, product details, or any other structured data. For example, a to-do list app might allow you to use PUT to update an existing task with new information.

   • Example of updating a task:

    const updatedTask = {
      title: 'Updated Task Title',
      completed: true
    };

    fetch('https://example.com/tasks/67', {
      method: 'PUT',
      headers: {
        'Content-Type': 'application/json'
      },
      body: JSON.stringify(updatedTask)
    });

PUT vs. POST: Key Differences

Though both PUT and POST can send data to a server, they have different purposes and behaviors:

Purpose:

• PUT: Primarily used for updating or replacing an existing resource. If the resource doesn’t exist, PUT can also create it.

• POST: Mainly used to create new resources or submit data that needs to be processed. POST doesn’t replace existing resources but adds new ones.

Data Handling:

• PUT: Replaces the entire resource with the new data. If a part of the resource is missing in the request, that part gets removed or replaced.

• POST: Adds or updates resources without replacing the entire thing. For example, when submitting a form, POST adds new data to the server without deleting what’s already there.

Idempotence:

• PUT: Is idempotent, so sending the same PUT request multiple times will always result in the same outcome. No matter how many times you update a resource using PUT, the result will be the same.

• POST: Is not idempotent, so submitting the same POST request multiple times could create duplicate resources or have different results.

Use Cases:

• PUT: Best used for updates and full replacements of resources. For instance, if you’re updating product details in an online store, PUT ensures that all the details are replaced with the new ones you send.

• POST: Suited for creating new entries or sending data that requires processing. For example, submitting an online order or filling out a contact form uses POST.

PATCH Method

The PATCH method is used to make partial updates to a resource on the server. Unlike the PUT method, which replaces the entire resource, PATCH allows you to update specific parts of a resource without sending the complete data again. This makes PATCH ideal for scenarios where you only want to tweak certain details without affecting other parts of the resource.

For example, if you have a user profile and want to update only the phone number, PATCH enables you to send just the new phone number while leaving the rest of the profile unchanged. This approach is more efficient and reduces the risk of unintended data loss.

Partial Updates with PATCH

PATCH is designed for making targeted changes to a resource. Here’s how it works:

• Targeted Changes: When you use PATCH, you specify only the fields you want to update. For instance, if a user updates their email address, you send a PATCH request containing just the new email, and everything else stays the same on the server.

• Efficiency: PATCH is more efficient than PUT because it allows you to send only the data that’s being changed. This can reduce bandwidth usage, especially when updating large resources where only a small part needs modification.

• Does Not Overwrite: Unlike PUT, PATCH does not replace the entire resource. It only updates the fields that are provided in the request, ensuring that other fields remain intact.

Example of a PATCH Request

Here’s a basic example of how you might use the PATCH method to update a specific field, such as changing a user's email address:

const updatedEmail = {
  email: 'new_email@example.com'
};

fetch('https://example.com/users/123', {
  method: 'PATCH',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify(updatedEmail)
})
.then(response => response.json())
.then(data => console.log('Email updated:', data))
.catch(error => console.error('Error:', error));

In this example, only the email field is being updated. The rest of the user profile, such as the username or address, remains unchanged.

When to Use PATCH Instead of PUT

There are specific scenarios where PATCH is more appropriate than PUT:

1. Updating Specific Fields: If you need to update only a part of a resource, like changing a user’s email, adding a tag to a blog post, or modifying a single attribute, PATCH is a better choice. It allows you to send only the fields that need updating, making the request more efficient.

   • Example: Updating a user's phone number.

    const updatedPhone = { phoneNumber: '123-456-7890' };

    fetch('https://example.com/users/123', {
      method: 'PATCH',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(updatedPhone)
    });

2. Avoiding Unintended Data Loss: When using PUT, leaving out any fields could result in the server removing or overwriting those fields. PATCH avoids this risk by only updating the specific fields provided, ensuring no accidental data loss.

   • Example: If you only want to update a user’s username but don’t want to overwrite other fields like their address or preferences, PATCH ensures only the username is updated.

3. Performance Considerations: PATCH is more efficient for large resources. For instance, if you're managing a database with extensive records and need to change a small portion, PATCH reduces the data sent to the server, improving performance and speeding up the process.

   • Example: Updating the status of a large order without modifying the entire order details.

    const updatedStatus = { status: 'shipped' };

    fetch('https://example.com/orders/987', {
      method: 'PATCH',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(updatedStatus)
    });

4. Frequent Updates: In applications where data changes frequently, PATCH makes it easier to update specific parts of a resource without affecting the entire structure. For instance, in an e-commerce platform, users might regularly update their shipping address or payment method, and PATCH can handle those frequent changes without requiring the entire user profile to be re-sent.

   • Example: Updating the delivery address for an order.

    const updatedAddress = {
      shippingAddress: '123 New Street, New City, Country'
    };

    fetch('https://example.com/orders/987', {
      method: 'PATCH',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(updatedAddress)
    });

Key Differences Between PUT and PATCH

Here’s a quick comparison of PATCH and PUT to clarify when each method is more appropriate:

PATCH is particularly valuable when you want to make partial updates, avoid overwriting other data, and improve the efficiency of your requests.

DELETE Method

The DELETE method is used to remove a resource from the server. When a DELETE request is made, the server deletes the specified resource, meaning it’s no longer accessible or available. This method is used for tasks like deleting a user account, removing a product from an online store, or clearing old data from a database.

Unlike GET or POST, DELETE doesn’t require sending a body in the request—just the URL of the resource you want to remove is enough. For example, to delete a specific blog post, a DELETE request is sent to the URL of that post, and the server takes care of removing it.

How DELETE Works

To delete a resource, you typically only need to provide the URL of the resource you want to remove. Unlike POST or PUT requests, DELETE requests generally don’t require a body.

Example:

If you want to delete a specific blog post, you can send a DELETE request to its URL:

fetch('https://example.com/posts/123', {
  method: 'DELETE'
})
.then(response => response.json())
.then(data => console.log('Resource deleted:', data))
.catch(error => console.error('Error:', error));

This tells the server to remove the blog post with ID 123.

Safely Using DELETE

DELETE requests can have a significant impact, so it’s important to use them carefully to avoid accidentally removing valuable data. Below are some key considerations for safely handling DELETE requests:

• Permanent Action: Once a DELETE request is processed, the resource is typically gone. In some cases, systems might implement "soft delete" functionality, where the resource is hidden but not completely removed. However, most use a "hard delete," where the resource is fully erased. Soft deletes can be useful for recovery purposes, allowing data to be restored if needed.

• Authentication: DELETE requests should be restricted to authorized users. Before performing a DELETE action, the server should validate that the user has permission to delete the resource. For example, only the owner of a user account should be able to delete it, not another user.

• Confirmation: Many applications prompt users to confirm their intention before processing a DELETE action. This extra step ensures users don't accidentally delete important data, especially for irreversible actions like account deletion.

Example of a Confirmation Step:

if (confirm("Are you sure you want to delete this post?")) {
  fetch('https://example.com/posts/123', {
    method: 'DELETE'
  })
  .then(response => console.log('Post deleted'))
  .catch(error => console.error('Error:', error));
}

• Reversibility (Soft Delete): For important data, it’s often useful to implement a soft delete, which doesn’t completely remove the data but marks it as deleted in the database. This allows the data to be restored later if needed. For example, many email systems keep deleted messages in a "Trash" folder until they are permanently removed.

Best Practices for Handling DELETE Requests

1. Require Authentication: Only authenticated users should be able to perform DELETE actions. This prevents unauthorized users from deleting resources they don't own. For example, users should only be allowed to delete their own data, not that of others.

   • Example: In a content management system (CMS), ensure that only the author of a post or an admin can delete it.

2. Use Confirmation Steps: For critical actions, confirm the user’s intent before proceeding. This is especially important for actions that cannot be undone, such as deleting an account or permanently removing a file.

   • Example: Show a prompt that says, "Are you sure you want to delete your account? This action cannot be undone."

3. Log Deletions: Keep a record of DELETE requests, including who initiated the request and when it occurred. Logging is important for accountability, troubleshooting, and data recovery in case of accidental deletions.

   • Example: In an e-commerce system, log details when a product is removed from the catalog, such as the user who initiated the request and the time of deletion.

4. Soft Delete for Critical Data: Implement a soft delete mechanism for data that may need to be restored later. This is particularly useful in scenarios like user accounts, where a user might want to recover their data after deletion.

   • Example: When a user "deletes" their account, it’s marked as inactive or hidden, rather than fully erased, allowing the user to recover it later.

5. Handle Errors Gracefully: If a DELETE request fails, the server should return an appropriate error message. For example, if the resource doesn’t exist or the user isn’t authorized to delete it, the server should respond with a message like "Resource not found" or "Unauthorized action."

   • Example: A DELETE request for a non-existent user could return a 404 Not Found response.

6. Double-Check URL Targeting: Before sending a DELETE request, ensure the URL points to the correct resource. Accidentally targeting the wrong resource could result in unintended data loss.

   • Example: If you are managing a to-do list and want to delete a single task, ensure the URL points specifically to that task and not to the entire list.

7. Communicate Results to the User: After a successful DELETE request, inform the user that the resource has been deleted. This can be done through a message or notification confirming the action.

   • Example: Show a message like "Item successfully deleted" after a product or post has been removed from the system.

DELETE Response

Typically, a successful DELETE request returns one of the following status codes:

• 200 OK: Indicates that the deletion was successful and includes a response body (for example, a message confirming the deletion).

• 204 No Content: The request was successful, but no content is returned in the response body. This is common when the resource is deleted, and there’s nothing to send back.

• 404 Not Found: Indicates that the resource to be deleted does not exist.

Example of a DELETE Request Response

If the DELETE request is successful and the resource is removed, a server might respond with a 204 No Content status:

HTTP/1.1 204 No Content

This response tells the client that the resource was successfully deleted but doesn’t return any additional data.

HEAD Method

The HEAD method is similar to the GET method but with a key difference: it only retrieves the headers of a resource, not the actual content.

When you send a HEAD request, the server responds with the same headers as a GET request, but without sending the body of the resource (like text, images, or files). This makes HEAD useful for checking information about a resource, such as its size or last modified date, without downloading the entire content.

For example, if you're managing a large file and want to check its size before downloading, you can use a HEAD request to get this information from the server without actually fetching the file itself.

How HEAD Compares to GET

• Same Headers, No Content: The HEAD request provides the same headers you’d receive with a GET request, such as Content-Type, Content-Length, Last-Modified, and so on. However, the response contains no body—just the metadata.

• Faster Requests: Because no body is included, HEAD requests are faster and consume less bandwidth than GET requests. This is helpful when you're only interested in details about the resource, not the content itself.

Use Cases for HEAD

1. Checking Resource Availability: You can use a HEAD request to check whether a resource (such as a webpage or file) exists without fetching the content. For example, if a URL returns a status code like 200 OK, you know the resource is there. A 404 Not Found status code would indicate that it’s not available.

2. Testing Links: If you manage a website with numerous external links, a HEAD request can test whether those links are still valid, saving you from loading the entire page. If a HEAD request returns an error code, you know the link is broken.

3. Fetching File Metadata: If you’re dealing with large files, you might want to check their size before downloading. A HEAD request allows you to gather metadata like the file size (Content-Length) and type (Content-Type) without retrieving the entire file.

4. Optimizing Caching: Browsers and applications can use HEAD requests to check if a resource has been updated since it was cached. The server returns headers like Last-Modified or ETag, and if these values haven’t changed, the cached version can be used, saving bandwidth and time.

5. API Efficiency: HEAD requests can be useful in APIs when a client needs to verify that data exists without downloading the entire response. For example, a request could check whether a record exists in a database without fetching the full details.

6. Server Health Monitoring: HEAD requests can be used to measure server performance. By testing the speed of a response without downloading content, developers can monitor server response times, check for issues, or determine if the server is up.

Best Practices for Using HEAD

• Efficient Testing: HEAD is ideal for validating resources or testing API endpoints without downloading unnecessary data.

• Caching: HEAD requests help with cache validation, ensuring that a resource is up-to-date without consuming bandwidth.

• No Side Effects: Like GET, HEAD should be safe and idempotent, meaning it should not alter the state of the resource. It’s used purely for retrieving information.

OPTIONS Method

The OPTIONS method is used to find out what actions are allowed on a specific resource. It allows a client (like a browser or an API) to ask the server, "What operations can I perform on this resource?" In response, the server lists the HTTP methods it supports for that resource, such as GET, POST, PUT, DELETE, and so on.

OPTIONS doesn’t perform any operation on the resource itself. Instead, it provides information about what the client can do. This makes it useful when you want to check what actions are allowed before actually making a request that changes or retrieves data.

For example, if you’re working with an API and want to see if it supports a DELETE method on a particular endpoint, you can send an OPTIONS request to get that information without affecting the resource.

Retrieving Supported Methods

1. Sending an OPTIONS Request: The client sends an OPTIONS request to a server, typically targeting a specific URL. This request serves as an inquiry about what actions are permitted on the resource at that endpoint.

2. Server’s Response: The server responds with an Allow header that lists the available HTTP methods for the resource. For example, it might return Allow: GET, POST, DELETE, meaning those methods can be used.

3. Testing for Methods: If you're unsure whether a particular method (like PATCH or DELETE) is supported by a server, you can send an OPTIONS request first to check. This avoids attempting methods that the server doesn’t support, which could result in errors.

Example:

OPTIONS /api/resource HTTP/1.1
Host: example.com

Server Response:

HTTP/1.1 200 OK
Allow: GET, POST, DELETE

How OPTIONS is Used in Cross-Origin Resource Sharing (CORS)

One of the most common uses of the OPTIONS method is in handling Cross-Origin Resource Sharing (CORS). CORS is a security feature that ensures resources on one domain aren’t accessed improperly by web pages from another domain.

CORS and Preflight Requests

When a browser needs to make a cross-origin request (for example, a request from domainA.com to api.domainB.com), the browser first sends an OPTIONS request, known as a preflight request, to the target server. The preflight request checks whether the actual request is allowed under the server’s CORS policy.

1. Preflight Request: The browser sends an OPTIONS request before the actual request (such as a POST or PUT). This request asks the server which methods are allowed, which domains can access the resource, and whether specific headers or credentials are permitted.

2. Server’s Response: The server responds with CORS headers, such as Access-Control-Allow-Methods, Access-Control-Allow-Origin, and Access-Control-Allow-Headers. This tells the browser whether the request can proceed and what methods or domains are allowed.

   Example Response:

    HTTP/1.1 204 No Content
    Access-Control-Allow-Origin: https://domainA.com
    Access-Control-Allow-Methods: GET, POST
    Access-Control-Allow-Headers: Content-Type
   

3. Ensuring Security: CORS and the preflight OPTIONS request ensure that cross-origin requests are only allowed when the server permits it. Without this security step, websites could make unauthorized requests to other domains.

4. Handling Complex Requests: If a request includes custom headers, uses HTTP methods other than simple ones like GET or POST, or sends credentials like cookies, the browser automatically sends an OPTIONS preflight request. If the server denies the request (that is, returns headers disallowing the action), the browser blocks the request.

Simplified Workflow:

• Browser: "Can I make this request to api.domainB.com?"

• Server: "Yes, you can use GET and POST, but only from domainA.com and with these headers."

• Browser: Proceeds with the actual request if the response permits.

Use Cases for the OPTIONS Method

• Discovering Available Methods: Useful for developers to check which HTTP methods a resource supports before performing an operation.

• CORS Preflight: Critical in web security to ensure that cross-origin requests are properly authorized.

• Improving API Efficiency: APIs can expose the supported methods for a resource via OPTIONS, making it easier for clients to understand what operations can be performed.

The OPTIONS method is thus essential in web applications for managing request permissions and improving security, particularly in cross-domain scenarios.

TRACE Method

The TRACE method is used to debug web applications and test how requests pass through networks. When you send a TRACE request, it triggers a loopback, where the server sends back the exact request it received, without any changes. This helps developers see if anything is modified as the request travels through different systems, like firewalls or proxies, before reaching the server.

In simple terms, TRACE allows you to trace the path your request takes from your client (like a browser or API tool) to the server and back. This method can be useful for identifying issues during the transmission of a request.

Understanding Loopback Diagnostics

Loopback diagnostics refers to the process of seeing how data is handled as it moves across networks, using TRACE to check if the original request remains intact. Here’s how it works:

1. Sending a TRACE Request: You send a TRACE request to a server. This request is usually small, containing basic information like the method, URL, and headers. It doesn't carry any extra data or payload like POST or PUT methods.

2. Server’s Response: Instead of responding with a resource, the server sends back the exact request it received. This includes the HTTP method, the URL, headers, and anything else in the original request. The server doesn’t modify or process the request—it just returns it exactly as it was received.

3. Tracing the Path: When the TRACE response comes back, it allows you to see the entire path the request took, including any changes made to the request headers or content. This is useful for diagnosing issues such as:

   • Proxy Servers: If your request passes through one or more proxy servers before reaching the destination, TRACE can show if those proxies have altered the request headers or content.

   • Network Firewalls: Some network firewalls might add or modify headers as your request passes through them. TRACE helps reveal these modifications.

   • Error Tracking: If a request fails to behave as expected, TRACE can help track where something went wrong in the transmission.

4. Effective Debugging: TRACE is especially helpful when debugging web applications or APIs. If your application is experiencing errors due to routing, proxies, or server configurations, TRACE lets you see the unaltered request, making it easier to pinpoint the issue.

Security Concerns with TRACE

Although TRACE can be useful for debugging, it is generally considered a security risk and is often disabled on most servers for several reasons:

1. XSS Attacks (Cross-Site Scripting): TRACE can expose sensitive information such as cookies or authentication tokens in the headers. Malicious actors could exploit TRACE to capture these details, leading to security breaches, especially if a vulnerability like cross-site scripting (XSS) is present. This makes TRACE a potential target for attackers trying to steal user data.

2. Request Modification Exposure: Since TRACE shows all modifications made to a request, it can also reveal how internal proxies and firewalls handle requests. This could give attackers insight into the internal workings of a network, making it easier for them to plan further attacks.

3. Disabling TRACE for Safety: For these reasons, TRACE is often disabled on most web servers to prevent abuse. In many modern web applications, more secure methods exist for debugging requests and tracing network paths, so TRACE is rarely necessary in everyday use.

4. Safer Alternatives: Developers can use safer diagnostic tools and logging features built into modern web frameworks and APIs. These alternatives provide similar insights without exposing security risks associated with TRACE.

CONNECT Method

The CONNECT method is mainly used to establish a tunnel between a client and a server through an intermediary, usually a proxy server. When the client sends a CONNECT request, the server creates a tunnel that allows encrypted data to flow between the client and the destination server. This method is crucial for securing connections, especially when dealing with HTTPS.

CONNECT does not handle any actual data on its own. Instead, it sets up a path for secure communication, allowing encrypted information to pass through proxies without being modified or inspected.

How CONNECT Works

1. Sending a CONNECT Request: A client, such as a web browser, sends a CONNECT request to the proxy server. This request includes the target server's hostname and port, typically the standard HTTPS port (443). For example, when accessing https://example.com, the browser sends a CONNECT request to the proxy server asking it to connect to that domain on port 443.

2. Establishing the Tunnel: The proxy server, upon receiving the CONNECT request, establishes a tunnel to the destination server. This tunnel allows encrypted communication to pass through without interference. The proxy simply forwards traffic between the client and the destination, acting as a relay.

3. Encrypted Communication: Once the tunnel is set up, the client and the destination server can communicate directly using a secure encryption protocol, such as TLS (used by HTTPS). The proxy cannot decrypt or modify the data passing through because it’s encrypted between the client and the server.

4. Secure Data Transfer: With the CONNECT method, sensitive data—such as login credentials, personal information, or financial transactions—can be transmitted securely between the client and the server, even when passing through proxies. The encrypted tunnel ensures that the data remains confidential and intact.

Example of a CONNECT Request and Response

• CONNECT Request:

    CONNECT example.com:443 HTTP/1.1
    Host: example.com
  

• Proxy Response (if the tunnel is successfully established):

    HTTP/1.1 200 Connection Established
  

Tunneling with CONNECT

The term tunneling in this context refers to creating a direct, secure link between the client and the destination server via a proxy. The proxy acts as a middleman but does not interfere with or access the encrypted data being transmitted through the tunnel.

Steps of the Tunneling Process:

• Sending the CONNECT Request: The client sends a CONNECT request to the proxy, specifying the destination server and port (for example, port 443 for HTTPS).

• Proxy Sets Up the Tunnel: The proxy server establishes a secure tunnel between the client and the destination server, forwarding traffic between the two endpoints.

• Encrypted Communication Begins: The client and the destination server communicate directly through the encrypted tunnel using HTTPS or another encryption protocol. The proxy forwards the encrypted traffic but cannot access or modify it.

Typical Use Cases of the CONNECT Method

1. HTTPS Through Proxies: One of the most common uses of the CONNECT method is enabling HTTPS traffic through proxies. In many corporate or network environments, internet traffic must pass through a proxy server. For secure websites using HTTPS, the CONNECT method allows the proxy server to establish a tunnel, forwarding encrypted traffic between the client and the destination server without inspecting the data.

   • Example: When you visit a secure banking website from a corporate network, your browser may need to pass through a corporate proxy. The CONNECT method is used to establish an encrypted tunnel between your browser and the bank's website, allowing sensitive data (such as login credentials) to pass through the proxy securely.

2. VPNs and Secure Channels: VPN (Virtual Private Network) services also rely on similar tunneling techniques to encrypt and route internet traffic securely. Some VPN services use CONNECT to create secure tunnels, ensuring that all data transmitted between the user and the internet is encrypted and safe from eavesdropping.

3. Accessing Blocked Content: In environments where certain websites are blocked (for example, schools or offices), CONNECT can sometimes be used to bypass restrictions by establishing a tunnel through a proxy. Although this practice may violate network policies, it illustrates how CONNECT can be used to establish secure, unmonitored access to otherwise blocked resources.

4. Custom Proxies: Developers may set up custom proxies to route application traffic for performance or security reasons. In these cases, CONNECT allows HTTPS or other secure traffic to pass through the proxy while maintaining privacy and security, as the proxy server cannot access the encrypted data inside the tunnel.

Security Considerations

While CONNECT is essential for secure communications, it also presents some security challenges:

• Bypassing Content Filters: Since CONNECT creates an encrypted tunnel that proxies cannot inspect, it can be used to bypass content filtering systems. This allows users to access restricted websites or services, which may violate organizational policies.

• Tunneling Malicious Traffic: CONNECT can be exploited by malicious actors to tunnel harmful or unauthorized traffic through a proxy. Because the traffic is encrypted, firewalls and security systems may not detect malicious activity.

• Mitigation: Many organizations address these risks by closely monitoring and restricting the use of the CONNECT method. Some proxies perform SSL interception to decrypt and inspect HTTPS traffic, though this introduces privacy concerns and may compromise user security.

Conclusion

HTTP methods are essential in enabling communication between web applications and servers. Each method, from GET to CONNECT, is designed for a specific task, such as sending data, retrieving information, updating resources, or setting up secure connections. Choosing the correct method for the job improves the efficiency and security of your application.

GET is ideal for retrieving data, POST and PUT help with creating and updating, PATCH handles partial updates, and DELETE removes resources. HEAD checks response headers without retrieving content, OPTIONS shows supported methods, and TRACE and CONNECT assist with debugging and secure communication.

Using the appropriate HTTP methods ensures your application runs efficiently and securely, offering a smooth experience for users.

If you have any questions or suggestions, feel free to reach out on LinkedIn. If you enjoyed this content, consider buying me a coffee to support the creation of more developer-friendly contents.

This action will send an HTTP request to the backend, along with all the necessary data, and the backend application will use that data to make changes to the database. After the action is complete, whether successful or not, an HTTP response will be sent back to the frontend, which will act accordingly based on the status of that response.

When these requests and responses are transferred back and forth, they need to follow a certain format so that both ends can understand each other. HTTP was created for this purpose. It is a standard network protocol that enables web applications to understand and communicate with each other.

What Are the HTTP Request Methods?

There are several methods you can use to send an HTTP request, and each of them serves a different purpose, as shown below:

The GET Method

The GET method is used to request data and resources from the server. When you send a GET request, the query parameters are embedded in the URL in name/value pairs like this:

http://example.com/index.html?name1=value1&name2=value2

Note that the question mark (?) denotes the beginning of a list of parameters. Each parameter forms a key/value pair (name=value), and the ampersand (&) is used to divide two different parameters.

The POST Method

The POST method is used to send data to the server, either adding a new resource or updating an existing resource. The parameters are stored in the body of the HTTP request.

POST /index.html HTTP/1.1
Host: example.com
name1=value1&name2=value2

The DELETE Method

This method removes a resource from the server.

The HEAD Method

The HEAD method works just like GET except that the HTTP response sent from the server will only contain the head but not the body. This means that if the server is "OK" with the request, it will give you a 200 OK response but not the resource you requested. You can only retrieve the resource with the GET method.

This is very useful when you are testing whether the server works. Sometimes, the resource may take a long time to be transmitted, and for testing purposes, you only need a 200 OK response to know that everything works properly.

The PUT Method

The PUT method is used to update existing resources, and it is similar to the POST method with one small difference.

When you PUT a resource that already exists, the old resource will be overwritten. And making multiple identical PUT requests will have the same effect as making it once.

When you POST identical resources, that resource will be duplicated every time the request is made.

What is the Fetch API?

For a long time, the JavaScript community lacked a standard way to send HTTP requests. Some people used XMLHttpRequest, aka AJAX, while others prefered external libraries such as Axios or jQuery.

The fetch API was introduced in 2015 as the modern, simplified, and standard way of making HTTP requests using JavaScript. It is natively supported, so there is no need to install any third-party libraries.

How to Send a GET Request Using JavaScript

The fetch API is promise-based, which means that it offers a clean and concise syntax for writing asynchronous operations. For example, this is how you can send a GET request using the fetch API.

fetch("https://jsonplaceholder.typicode.com/users")
  .then((response) => {
    // If the response is not 2xx, throw an error
    if (!response.ok) {
      throw new Error("Network response was not ok");
    }

    // If the response is 200 OK, return the response in JSON format.
    return response.json();
  })
  .then((data) => console.log(data)) // You can continue to do something to the response.
  .catch((error) => console.error("Fetch error:", error)); // In case of an error, it will be captured and logged.

You can also include custom options with the request, such as custom headers, authorization tokens, and so on.

fetch("https://jsonplaceholder.typicode.com/users", {
  headers: {
    "Content-Type": "application/json",
    "Authorization": "your-token-here",
  },
  credentials: "same-origin",
})
  .then(. . .);

How to Send a POST Request Using JavaScript

When sending a POST request, things get a bit more complex because you need to send data to the server with the request body. This could get complicated depending on the kind of data you're sending and your specific use case.

For example, the following code sends JSON data to the backend:

fetch("https://jsonplaceholder.typicode.com/users", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    name: "John Doe",
    email: "johndoe@example.com",
  }),
});

There are a few things you must pay attention here. First of all, you must explicitly specify the request method. If you leave this out, the default GET method will be used.

Also, the request body only accepts string data, so you must use the stringify() method to convert JSON into a string before assigning it to the request body.

This is also why it is important to include the Content-Type header, which lets whoever is on the receiving end know how to parse the request body.

However, things are usually more complex in practice. For example, when working with web forms, instead of JSON, you are likely using the x-www-form-urlencoded form encoding, in which case the request can be sent like this.

The following example assumes you understand what event handlers are.

document.addEventListener("DOMContentLoaded", function () {
  const form = document.querySelector("form");
  const usernameInput = document.getElementById("username");
  const emailInput = document.getElementById("email");

  const formData = new URLSearchParams();

  usernameInput.addEventListener("input", function () {
    formData.set("username", usernameInput.value);
  });

  emailInput.addEventListener("input", function () {
    formData.set("email", emailInput.value);
  });

  form.addEventListener("submit", async function (event) {
    event.preventDefault(); // Prevent the default form submission action

    await fetch("https://jsonplaceholder.typicode.com/users", {
      method: "POST",
      body: formData.toString(),
      headers: {
        "Content-Type": "application/x-www-form-urlencoded",
      },
    });
  });
});

If you need to upload files to the backend, you'll need the multipart/form-data form encoding instead.

document.addEventListener("DOMContentLoaded", function () {
  const form = document.getElementById("myForm");
  const usernameInput = document.getElementById("username");
  const emailInput = document.getElementById("email");
  const pictureInput = document.getElementById("picture");

  const formData = new FormData();

  usernameInput.addEventListener("input", function () {
    formData.set("username", usernameInput.value);
  });

  emailInput.addEventListener("input", function () {
    formData.set("email", emailInput.value);
  });

  pictureInput.addEventListener("change", function () {
    formData.set("picture", pictureInput.files[0]);
  });

  form.addEventListener("submit", async function (event) {
    event.preventDefault(); // Prevent the default form submission

    await fetch("https://jsonplaceholder.typicode.com/users", {
      method: "POST",
      body: formData,
    });
  });
});

Note that when using the FormData() to construct the request body, the Content-Type will be locked into multipart/form-data. In this case, it is not necessary to set a custom Content-Type header.

How to Send a PUT Request Using JavaScript

The PUT request works similarly to POST, but you must remember to set method to PUT.

fetch("https://jsonplaceholder.typicode.com/users", {
  method: "PUT",
  headers: {
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    id: "123"
    name: "John Doe",
    email: "johndoe@example.com",
  }),
});

Realistically, you'll have to provide an id, or any other key that enables you to locate the record to be updated in the backend.

How to Send a DELETE Request Using JavaScript

The DELETE request works similarly to PUT, but remember to set method to DELETE.

fetch("https://jsonplaceholder.typicode.com/users/123", {
  method: "DELETE",
});

And similarly, remember to provide an id so that the backend application knows which record to delete.

How to Send a Request Using XMLHttpRequest (AJAX)

Besides fetch(), it is also possible to make an HTTP request using XMLHttpRequest. The following example demonstrates how to make a GET request to the endpoint https://jsonplaceholder.typicode.com

var xhr = new XMLHttpRequest();
xhr.open("GET", "https://jsonplaceholder.typicode.com/users", true);
xhr.onload = function () {
  if (xhr.status >= 200 && xhr.status < 300) {
    console.log(JSON.parse(xhr.responseText));
  } else {
    console.error("Error:", xhr.statusText);
  }
};
xhr.onerror = function () {
  console.error("Request failed");
};
xhr.send();

The syntax is a bit more complex, as XMLHttpRequest relies on callback functions to work with asynchronous operations, which means it is easy to lead to what is known as the callback hell, where you have layers upon layers of callback functions, making your code base difficult to read and maintain.

However, XMLHttpRequest does have some advantages. Due to the fact that XMLHttpRequest is much older compared to fetch(), it is more widely supported. You should consider using XMLHttpRequest when your web app needs to be compatible with older browsers.

How to Send a Request Using External Libraries

Aside from the built-in methods, you can also send HTTP requests using third-party libraries. For instance, this is how you can send a GET request using jQuery:

$.get("https://api.example.com/data", function (data) {
  console.log(data);
}).fail(function (error) {
  console.error("Error:", error);
});

jQuery is one of the most popular JavaScript libraries. It aims to fix the part of JavaScript that is difficult to use, and it has been pretty successful at that.

In recent years, jQuery has lost some popularity as vanilla JavaScript has improved over the years and the problems that used to bother people have been fixed. It is no longer the go-to choice for creating JavaScript applications, especially for newer developers.

Alternatively, you could go with Axios, which is a promise-based HTTP client just like fetch(), and it has been people's favorite for a very long time before fetch() came.

axios
  .get("https://api.example.com/data")
  .then((response) => console.log(response.data))
  .catch((error) => console.error("Axios error:", error));

Axios and fetch() have very similar syntax as they are both promise-based. The main difference between them is that fetch() is built-in, while Axios requires you to install an external library. However, Axios is much more feature-rich, as it comes with request/response interceptors, automatic JSON handling, and built-in timeouts.

Conclusion

We introduced four different ways you could send HTTP requests using JavaScript in this tutorial. It is up to you to decide which is best for your project.

The fetch API is the modern and standard way of making HTTP requests using JavaScript. It has a relatively simple syntax, which makes your project easier to maintain.

XMLHttpRequest is the legacy method of sending HTTP requests. It is generally not recommended for use in new projects, but if your project needs to be compatible with legacy browsers, XMLHttpRequest might still come in handy.

jQuery is an external package that can do a lot of things, including sending HTTP requests. Although the significance of jQuery has been fading in recent years, it is still used in many older projects, and you might encounter it in your work as a JavaScript developer.

Axios is a third-party library used to send HTTP requests. It has a very similar syntax to the fetch API but comes with a lot more advanced features. It is up to you to decide if you need these features. If not, it is generally recommended to use fetch() instead.

To learn more about JavaScript and web development, visit thedevspace.io

For example, let's say you have a button that only opens a door when pressed. This button does not have the ability to close the door, so it stays open even when it's pressed repeatedly. It simply remains in the state it was changed to by the first press.

This same logic applies to HTTP methods that are idempotent. Operating on idempotent HTTP methods repeatedly won't have any additional effect beyond the initial execution.

Understanding idempotence is important for maintaining the consistency of HTTP methods and API design. Idempotence has a significant impact on API design, as it influences how API endpoints should behave when processing requests from clients.

In this tutorial, I'll explain the concept of idempotence and the role it plays in building robust and functional APIs. You'll also learn about what safe methods are, how they relate to idempotence, and how to implement idempotency in non-idempotent methods.

Prerequisites

Before understanding and implementing idempotence in API design, it's essential to have a solid foundation in the following areas:

• RESTful Principles
• Fundamentals of HTTP methods
• API Development
• HTTP Status codes
• Basics of Web development.

Idempotence Example

Let's start off with an example of idempotence in action. We'll create a function that uses the DELETE method to delete data from a web page:

from flask import Flask, jsonify, abort

app = Flask(__name__)

web_page_data = [
   {"id": 1, "content": "Row 1 data"},
   {"id": 2, "content": "Row 2 data"},
   # Add more rows as needed
]

@app.route('/delete_row/<int:row_id>', methods=['DELETE'])
def delete_row(row_id):
   # Find the row to delete
   row_to_delete = next((row for row in web_page_data if row["id"] == row_id), None)

   if row_to_delete:
       # Simulate deletion
       web_page_data.remove(row_to_delete)
       return jsonify({"message": f"Row {row_id} deleted successfully."}), 200
   else:
       abort(404, description=f"Row {row_id} not found.")

if __name__ == '__main__':
   app.run(debug=True)

This function is expected to delete the rows chosen by the user. Now because of the idempotent nature of the DELETE method, the data will be deleted once, even when called repeatedly. But subsequent calls will return a 404 error since the data has already been deleted by the first call.

Let’s look at another example with the GET method. The GET method is used to retrieve data from a resource. Let’s create a function that uses the GET method to retrieve a username:

import requests

def get_username():
    url = 'https://api.example.com/get_username'
    try:
        response = requests.get(url)
        if response.status_code == 200:
            return response.json()['username']
        else:
            return None
    except requests.RequestException as e:
        print(f"Error occurred: {e}")
        return None

# Usage
username = get_username()
if username:
    print(f"The username is: {username}")
else:
    print("Failed to retrieve the username.")

In this example, we define the get_username() function, which sends a GET request to the API endpoint to retrieve the username. If the request is successful, we extract the username from the JSON response and return it. But if any error occurs during the request, we handle it and return None.

Now the idempotent nature of the GET method ensures that even if you call get_username() multiple times, the same username will be fetched from the API each time. The result will always be the same which is to fetch the username from the resource.

Idempotent vs. Non-Idempotent HTTP Methods:

HTTP methods play crucial roles in determining how data is fetched, modified, or created when interacting with APIs. And Idempotency is one of the important concepts that influences data consistency and reliability in the methods used .

Here's a breakdown of the different methods based on their idempotency.

Idempotent methods:

• GET
• HEAD
• PUT
• DELETE
• OPTIONS
• TRACE

Non-idempotent methods:

• POST
• PATCH
• CONNECT

Safe Methods

In our previous example, we used the GET method to retrieve a username and this had no side effect on the server. This is because it is a safe method.

A safe method is a type of method that doesn’t modify the server’s state or the resource being accessed. In other words, they perform read-only operations used to retrieve data or for resource representation.

When you make a request using a safe method, the server does not perform any operations that modify the resource's state. Like in our previous example, we retrieved the username from the webpage which is the resource without changing anything in the server.

All safe methods are automatically idempotent, but not all idempotent methods are safe. This is because while idempotent methods produce consistent results when called repeatedly, some of them may still modify the server's state or the resource being accessed.

Like in our first example, the DELETE method is idempotent, because deleting a resource multiple times will have the same effect. But it's not safe, as it changes the server's state by removing the resource.

Here’s a classification of HTTP methods based on their safe status:

Safe methods:

• GET
• OPTIONS
• HEAD

Unsafe methods:

• DELETE
• POST
• PUT
• PATCH

Why is POST not idempotent?

POST is an HTTP method that sends information to a server. When you make a POST request, you typically submit data to create a new resource or trigger a server-side action. Therefore, making the same request multiple times can result in different outcomes and side effects on the server. This can lead to duplicated data, starting server resources, and reducing performance because of the repeated action.

Unlike idempotent methods like GET, PUT, and DELETE, which have consistent results regardless of repetition, POST requests can cause changes to the server's state with each invocation.

POST requests often create new resources on the server. Repeating the same POST request will generate multiple identical resources, potentially leading to duplication.

This is similar to DELETE which is an idempotent method but not a safe method. Deleting the last entry in a collection using a single DELETE request would be considered idempotent. But if a developer creates a function that deletes the last entry, that would trigger DELETE multiple times. Subsequent DELETE calls would have different effects, as each one removes a unique entry. This would be considered non-idempotent.

How to Achieve Idempotency with Non-Idempotent Methods

Idempotency isn't only a property inherent to certain methods – it can also be implemented as a feature of a non-idempotent method.

Here are some techniques to achieve idempotency even with non-idempotent methods.

Unique Identifiers

Adding unique identifiers to every request is one of the most common techniques used to implement idempotency. It works by tracking whether the operation has already been performed or not. If it's a duplicate (a repeat request), the server knows it's already dealt with that request and simply ignores it, ensuring that no side effects occur.

Here's an example of how it works:

from uuid import uuid4

def process_order(unique_id, order_data):
    if Order.objects.filter(unique_id=unique_id).exists():
        return HttpResponse(status=409)  # Conflict
    order = Order.objects.create(unique_id=unique_id, **order_data)
    return HttpResponse(status=201, content_type="application/json")

# Example usage
post_data = {"products": [...]}
headers = {"X-Unique-ID": str(uuid4())}
requests.post("https://api.example.com/orders", data=post_data, headers=headers)

In this code snippet, we define a function called process_order that creates orders in an API, using unique identifiers to implement idempotency.

Here's a breakdown of the code:

Importing the Unique Identifier Generator:

from uuid import uuid4: The code snippet starts by importing the uuid4 function from the uuid module. This function generates unique identifiers, which are used to achieve idempotency in this code.

Defining the process_order Function:

def process_order(unique_id, order_data): This line defines a function named process_order that takes two arguments:

• unique_id: This is a string representing a unique identifier for the request. This ensures no duplicate orders are created with the same identifier.
• order_data: This is a dictionary containing the actual order data, like product information and customer details.

Checking for Existing Orders:

if Order.objects.filter(unique_id=unique_id).exists(): This line checks if an order with the same unique_id already exists in the database.

Order.objects.filter(unique_id=unique_id).exists() queries the Order model for orders with the matching unique_id and checks if any orders were found in the query result. If an order is found, it means the same request was already processed.

Handling existing orders:

return HttpResponse(status=409): If an order with the same unique_id already exists, the function immediately returns an HTTP response with status code 409 indicating a conflict. This prevents duplicate orders from being created.

Creating a new order (if unique):

order = Order.objects.create(unique_id=unique_id, **order_data ): This line only runs if no existing order is found.

Order.objects.create: creates a new object in the Order model.

unique_id=unique_id sets the unique_id attribute of the new order to the provided unique_id.

order_data: spreads the dictionary order_data as keyword arguments to the order model's constructor, setting other relevant attributes like products and customer information.

Sending a success response:

return HttpResponse(status=201, content_type="application/json"): If the order creation is successful, the function will return an HTTP response with status code 201 which shows a successful creation. It also specifies the response content type as JSON, assuming the order data might be returned in JSON format.

post_data = {"products": [...]}: an example request, defines a dictionary containing the actual order data, like a list of products.

headers = {"X-Unique-ID": str(uuid4())}: This line creates a dictionary containing a custom header named X-Unique-ID. It generates a unique identifier string using uuid4() and adds it to the header.

requests.post("https://api.example.com/orders", data=post_data, headers=headers): This line sends a POST request to the API endpoint https://api.example.com/orders with the provided post_data and headers.

How does this implement idempotence?

It does so by using a unique identifier (unique_id) for each order.

It checks if an order with the same identifier already exists in the database. If it returns true, it returns a 409 Conflict status. Otherwise, it creates a new order and responds with a 201 Created status. The unique identifier prevents duplicate orders, making the system idempotent.

Token-based Authorization

Token-based authorization is a form of authorization that assigns temporary tokens for each non-idempotent action. Once the action is completed, the token is invalidated. If the same request comes again with the same token, the server recognizes it as invalid and refuses the request, thereby preventing duplicate actions.

// Generate a unique token for this action
const token = generateToken();

fetch("https://api.example.com/create-user", {
    method: "POST",
    body: JSON.stringify({ username, password }),
    headers: {
        Authorization: `Bearer ${token}`,
        "Content-Type": "application/json",
    },
})
    .then(response => {
        // Handle successful response
        if (response.ok) {
            // Do something with the successful response
        } else {
            // Handle non-successful response
        }
    })
    .catch(error => {
        // Handle error
        console.error("Error occurred:", error);
    })
    .finally(() => {
        // Invalidate token after successful action or in case of an error
        invalidateToken(token);
    });

// Simple implementation for generating a token
function generateToken() {
    return Math.random().toString(36).substr(2);
}

// Simple implementation for invalidating a token
function invalidateToken(token) {
    // Add your logic to invalidate the token, e.g., remove it from storage
}

Here's a breakdown of the code:

Generating a unique token:

const token = generateToken(): This line calls a function named generateToken() (which is assumed to be defined elsewhere) that generates a unique token string. This token will be used for authorization and idempotency.

Sending the POST request:

fetch("https://api.example.com/create-user", { ... }): This line uses the fetch API to send a POST request to the API endpoint https://api.example.com/create-user.

method: "POST": This specifies the HTTP method as POST, indicating the intention to create a new user.

body: JSON.stringify({ username, password }): This defines the request body with user details like username and password. The data is converted to JSON format before sending.

headers: { Authorization:Bearer ${token}}: This sets the Authorization header in the request. The header value includes the generated token prefixed with "Bearer ".

Handling the Response:

.then(response => { ... }): This block defines the code to execute if the request is successful. You would handle things like storing user information or redirecting the user upon successful user creation.

.catch(error => { ... }): This block defines the code to execute if the request encounters an error. You would handle any error messages or handle specific error scenarios here.

Invalidating the Token:

invalidateToken(token): This line calls a function named invalidateToken(token) ( which is assumed to be defined elsewhere) which would likely mark the used token as invalid. This ensures the same token cannot be used for subsequent requests, adding to the idempotency guarantee.

How does this implement Idempotence?

This code snippet uses token-based authorization to implement idempotency in a POST request to create a user on an API. If a user creation request is accidentally sent multiple times, a new unique token is generated each time and used in the Authorization header.

The API server can recognize and verify the unique token, and since the user creation action has already been performed (assuming it's successful the first time), it won't create duplicate users due to subsequent identical requests.

ETag Header:

An ETag header (Entity Tag) is an HTTP header used for web cache validation and conditional requests. It is mainly used for PUT requests, that only update resources if they haven't changed since the last check.

When you want to update a resource, the server sends you its ETag which is then included in your PUT request along with the updated data. If the ETag hasn't changed (meaning the resource remains the same), the server accepts the update. But if the ETag has changed, the server rejects the update, preventing it from overwriting someone else's changes.

def update_article(article_id, content):
    # Get existing article and its ETag
    article = Article.objects.get(pk=article_id)
    etag = article.etag

    # Check if ETag matches with request header
    if request.headers.get("If-Match") != etag:
        return HttpResponse(status=409)  # Conflict

    # Update article content and generate new ETag
    article.content = content
    article.save()
    new_etag = article.etag

    # Return success response with updated ETag
    return HttpResponse(status=200, content_type="text/plain", content=new_etag)

In this code snippet, we define a function called update_article that allows you to update the content of an existing article based on its ID and new content. It implements idempotency using the ETag header technique.

Here's a step-by-step explanation of how it works;

Getting the Existing Article and its ETag:

article = Article.objects.get(pk=article_id): This line fetches the article with the provided article_id from the database using the Article model.

etag = article.etag: This line extracts the ETag value from the retrieved article object. The ETag serves as a unique identifier for the article's current state.

Checking for a Match:

if request.headers.get("If-Match") != etag: This line checks if the ETag header provided in the request matches the ETag of the retrieved article.

return HttpResponse(status=409): If the ETag doesn't match, it indicates that the article might have been updated by another request since the client retrieved its information. The function returns a 409 Conflict response, which prevents accidental data corruption.

Updating the Article Content and generating a new ETag:

article.content = content: This line updates the article's content with the new content received in the request.

article.save(): This line saves the updated article back to the database.

new_etag = article.etag: This line retrieves the new ETag generated for the updated article after saving it.

Returning the Success Response with the new ETag:

return HttpResponse(status=200, content_type="text/plain", content=new_etag): returns a successful 200 OK response, including the content type ("text/plain") and the updated ETag of the article in the response body.

How does this implement idempotence?

This code ensures that if the same update request is sent multiple times with the same ETag, the update will only be performed once, preventing duplicate updates and maintaining data consistency. The new ETag is then provided in the response to help the client keep track of the article's state for future interactions.

Conclusion

In this tutorial, we highlighted the difference between safe methods like GET, which retrieves data without side effects, and non-idempotent methods like POST, which can have different outcomes with each repetition.

We also explored techniques you can apply to achieve idempotence in non-idempotent methods, emphasizing the importance of designing APIs that prioritize consistency and reliability.

One crucial aspect of HTTP is the request method, which indicates the type of operation the client wants to perform on a resource.

This article will explore three common HTTP request methods — Call, Put, and Post — and their applications in JavaScript web development.

How HTTP Works

HTTP (Hypertext Transfer Protocol) is the foundation of communication on the World Wide Web. It is a protocol that governs how data is transmitted and received between clients (web browsers) and servers (web servers) over the internet.

When you enter a URL (Uniform Resource Locator) in your web browser and hit enter, your browser sends an HTTP request to the server hosting the website associated with that URL. The server then processes the request and sends back an HTTP response containing the requested data, such as a webpage, an image, or other resources.

HTTP uses a client-server model, where the client (typically a web browser) sends requests to the server, and the server responds with the requested data. One important aspect of HTTP is the concept of request methods, also known as HTTP verbs or methods.

Request methods are used to indicate the type of operation the client wants to perform on a resource on the server. HTTP defines several request methods, including Call, Put, Post, Delete, and more, each with its specific purpose and behavior.

These request methods are used to communicate the client's intention to the server and determine how the server should handle the request. Let's focus on three common request methods: Call, Put, and Post.

How to Use the Call Method

In the context of an HTTP Request, the call method is called the GET method. It is used to retrieve data from a resource on the server. When you make a Call request, you ask the server to provide you with the data of a particular resource.

The Call method is considered "safe" and "idempotent." This means it should not have any side effects on the server and can be repeated multiple times without changing the outcome. In other words, making the same Call request multiple times should not result in any changes on the server.

In JavaScript web development, you often use the Call method to fetch data from APIs or retrieve resources from the server.

For example, you may use the Fetch API in JavaScript to request a Call to an API and retrieve data in JSON format:

fetch("https://jsonplaceholder.typicode.com/posts?_limit=5")
  .then((response) => response.json())
  .then((data) => console.log(data))
  .catch((error) => console.error(error));

In this example, the Call request is made to the URL ‘https://jsonplaceholder.typicode.com/posts’ to fetch data from the server (?_limit=5 is added to reduce the data fetched from 100 to 5). The response from the server is then parsed as JSON, and the retrieved data is logged to the console. You can now make use of the data within your application.

How to Use the Put Method

The Put method is used to update data on the server or create a new resource if it does not already exist.

When you make a Put request, you ask the server to update the data of a particular resource or create a new resource with the provided data.

The Put method is considered "idempotent" but not "safe." This means that making the same Put request multiple times will not result in different outcomes but may have side effects on the server.

In JavaScript, you can use the Put method to send data to the server to update resources. For example, you may use the Fetch API to make a Put request with updated data to update a user's profile information on the server:

const dataToUpdate = {
  id: 1,
  title: "Hello freeCodeCamp",
  body: "Welcome to freeCodeCamp",
  userId: 1
};

fetch("https://jsonplaceholder.typicode.com/posts/1", {
  method: "PUT",
  headers: {
    "Content-type": "application/json; charset=UTF-8"
  },
  body: JSON.stringify(dataToUpdate)
})
  .then((response) => response.json())
  .then((data) => console.log(data))
  .catch((error) => console.error(error));

In this example, the Put request is made to the URL ‘https://jsonplaceholder.typicode.com/posts/1’ with the updated data in the request body. The server will then update the resource's data with ID 1 based on the provided data in the request body.

The response from the server, containing the updated data, is then parsed as JSON and logged to the console.

{
  "id": 1,
  "title": "Hello freeCodeCamp",
  "body": "Welcome to freeCodeCamp",
  "userId": 1
}

Note: The PUT method is used to update data. The post of id 1 was updated.

How to Use the Post Method

The POST method is used to submit data to the server to create a new resource.

When you make a Post request, you ask the server to create a new resource with the data provided in the request body. The Post method is not considered "idempotent" or "safe," as making the same Post request multiple times may create multiple resources with different outcomes.

In JavaScript, you can use the Post method to send data to the server to create new resources. For example, you may use the Fetch API to make a Post request with new data to create a new user account on the server:

const newData = {
  title: "Hello freeCodeCamp",
  body: "Welcome to freeCodeCamp",
  userId: 1
};

fetch("https://jsonplaceholder.typicode.com/posts", {
  method: "POST",
  headers: {
    "Content-type": "application/json; charset=UTF-8"
  },
  body: JSON.stringify(newData)
})
  .then((response) => response.json())
  .then((data) => console.log(data))
  .catch((error) => console.error(error));

In this example, the Post request is made to the URL ‘https://jsonplaceholder.typicode.com/posts’ with the new data in the request body. The server will then create a new resource with the provided data, and the response from the server, containing the newly created resource data, is parsed as JSON and logged to the console.

{
  "title": "Hello freeCodeCamp",
  "body": "Welcome to freeCodeCamp",
  "userId": 1,
  "id": 101
}

Note: A new id of 101 is created because this is new data that does not exist before, so a unique ID is assigned to it.

Best Practices and Considerations

1. Use appropriate request methods: It's important to choose the appropriate one based on the intended operation on the server-side resource. Use Call for custom actions or functions, Put for updating existing resources, and Post for creating new ones.

2. Follow RESTful principles: If you're building a RESTful API, it's important to follow the principles of Representational State Transfer (REST), which includes using standard HTTP request methods for CRUD operations. Use Get for retrieving resource data, Put for updating, Post for creating new resources, and Delete for deleting resources.

3. Consider idempotency and safety: Put requests are idempotent, meaning making the same request multiple times will have the same outcome as making it once. Post requests are not idempotent, and making the same request multiple times may create multiple resources with different outcomes. Consider your operation's idempotency and safety requirements when choosing the appropriate request method.

Wrapping Up

HTTP is a crucial protocol that governs how data is transmitted and received between clients and servers on the World Wide Web. Request methods in HTTP, such as Call, Put, and Post, indicate the type of operation the client wants to perform on a resource on the server.

Understanding how these request methods work is essential in web development, as they determine how the server will handle the requests and what actions will be taken on the resources.

By utilizing the appropriate request methods in your web applications, you can effectively communicate with servers and manage resources reliably and efficiently.

Have fun coding!

Embark on a journey of learning! Browse 200+ expert articles on web development. Search 'request' for a deep dive into POST, GET, and making HTTP requests with React and JavaScript. Check out my blog for more captivating content from me.

There are various ways to design web applications, including GraphQL, SOAP, Falcor, gRPC, WebSockets, and Serverless Functions, with REST being the most popular (according to the 2021 State-of-API survey by Postman). And at the heart of all these architectures is HTTP.

What to Learn Along with HTTP

To understand HTTP, it is helpful to have a basic understanding of the following concepts:

1. Networking: Knowledge of how computers communicate with each other over networks is essential for understanding HTTP. This includes concepts such as IP addresses, DNS, and routing.
2. Web architecture: HTTP is a key part of web architecture, so understanding how web applications and websites are built can help you understand HTTP better. This includes concepts such as HTML, CSS, and JavaScript.
3. Server-side programming: HTTP is used to communicate between web browsers and servers, so understanding how servers work and how to build server-side applications can help you understand how HTTP works.
4. Client-side programming: HTTP is also used to communicate between web browsers and client-side applications, so understanding how to build client-side applications using JavaScript can also be helpful.

What to Expect in This Article

• How the HTTP protocol works.
• How to make network requests with Chrome and Postman.
• How to upload data with the HTTP POST method in Postman.

By the end of the article, readers should have a basic understanding of HTTP, as well as the tools and resources available for testing and troubleshooting applications.

Table of Contents

• Introduction to HTTP
• What is the HTTP Request-Response Cycle?
• How to Create HTTP Requests
• What is an HTTP Request URL?
• What Are HTTP Request Methods?
• What Are HTTP Request Headers?
• What is an HTTP Request Body?
• What is an HTTP Response?

Introduction to HTTP

HTTP (Hypertext Transfer Protocol) is a protocol used for exchanging information over the internet. HTTP is like the delivery system for information on the internet. It makes sure information goes from one place to another, like how ships carry goods across the ocean. It's the foundation of the World Wide Web.

HTTP is what makes the internet work. It's a way for web browsers and servers to talk to each other and send things like web pages back and forth. It's important for people who build websites and web applications to know how it works.

Without HTTP, it would be difficult to imagine how the internet would work. There would be no web pages, no URLs, and no hyperlinks. Instead, users would need to know the exact IP address of the server hosting the information they want to access, and they would need to use a low-level protocol like TCP/IP to transfer data.

What is the HTTP Request-Response Cycle?

Communication in HTTP centers around a concept called the Request-Response Cycle.

The request-response cycle is the process by which a client (such as a web browser or a mobile app) communicates with a server to retrieve resources or perform actions. The cycle involves several steps:

1. The client initiates a request to the server by sending an HTTP request message, which contains information such as the requested resource and any additional parameters.
2. The server receives the request message and processes it, using its resources to generate a response message.
3. The server sends the response message back to the client, which typically contains the requested resource (such as a web page) and any additional information or metadata.
4. The client receives the response message and processes it, usually by rendering the content in a web browser or displaying it in an app.
5. The client may initiate additional requests to the server, repeating the cycle as needed.

How to Create HTTP Requests

To create a valid HTTP request, you need the following:

• A URL.
• The HTTP method.
• A list of headers (request headers).
• The request body.

Here's an example of an HTTP request header, with three lines:

GET /watch?v=8PoQpnlBXD0 HTTP/1.1
Host: www.youtube.com
Cookie: GPS=1; VISITOR_INFO1_LIVE=kOe2UTUyPmw; YSC=Jt6s9YVWMd4

1. The first line specifies the HTTP method, path, and protocol version. In this case, it is a GET request for the video located at the path /watch?v=8PoQpnlBXD0 using the HTTP/1.1 protocol.
2. The second line specifies the host of the website, which is www.youtube.com.
3. The third line contains a cookie header, which is used for sending and storing small pieces of data on the client side. In this case, the cookie header contains three values: GPS=1, VISITOR_INFO1_LIVE=kOe2UTUyPmw, and YSC=Jt6s9YVWMd4. These values can be used by YouTube to track and personalize the user's experience.

What is an HTTP Request URL?

When a web browser attempts to access an image on the internet, it sends a request to the server using a URL. This URL is unique and points to a specific resource on the server.

A resource can be anything that has a name and can be accessed with a unique identifier like a user, product, article, document, or image. You can think of resources as nouns.

What Are HTTP Request Methods?

The request method tells the server what kind of action the client wants the server to take. The most common methods are:

What Are HTTP Request Headers?

HTTP request headers are additional pieces of information that are sent by the client as part of an HTTP request. They have a name/value format. That is:

Name: Value

These headers provide context and additional instructions to the server, which can be used to process the request or customize the response.

Here's an example of an HTTP request header:

GET /api/data HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.82 Safari/537.36
Accept: application/json
Accept-Language: en-US,en;q=0.5
Authorization: Token abc123
Cache-Control: no-cache
Connection: keep-alive
Referer: https://www.google.com/
Pragma: no-cache

In this example, the GET method is used to send a request to the /api/data endpoint on the example.com server using HTTP/1.1 protocol. The request includes ten headers:

What is an HTTP Request Body?

In HTTP, the request body is the data that is sent from the client to the server as part of an HTTP request. The example below shows how to upload an image to the Cat API Server:

And here's what the request looks like:

POST /v1/images/upload HTTP/1.1
Host: api.thecatapi.com
x-api-key: API_KEY
Content-Length: 232
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW

------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="file"; filename="/C:/Users/USER/Downloads/cat1.jpg"
Content-Type: image/jpeg

(data)
------WebKitFormBoundary7MA4YWxkTrZu0gW--

The request includes these headers:

1. Host: This header specifies the hostname of the server that the client is trying to connect to.
2. Content-Type: The request is uploading an image file named cat1.jpg using a type of data called multipart/form-data. The image is in JPEG format and its content is included in the request body.
3. x-api-key: This header provides an API key for authentication purposes.
4. Content-Length: This header specifies the length of the request body in bytes. The value of this field is 232.

When the server receives this request, it will parse the request body and use it to create a new entry in the Cat API database. The server will then return a response that includes information about the new entry, such as the image URL and the database ID.

What is an HTTP Response?

An HTTP response is the message that a server sends back to a client in response to an HTTP request. It usually consists of a status line, headers, and a message body:

HTTP/1.1 200 OK
Date: Sun, 28 Mar 2023 10:15:00 GMT
Content-Type: application/json
Server: Apache/2.4.39 (Unix) OpenSSL/1.1.1c PHP/7.3.6
Content-Length: 1024

{
    "name": "John Doe",
    "email": "johndoe@example.com",
    "age": 30,
    "address": {
        "street": "123 Main St",
        "city": "Anytown",
        "state": "CA",
        "zip": "12345"
    }
}

The status line contains the HTTP version, a status code indicating the outcome of the request, and a corresponding message.

The headers provide additional information about the response, such as the content type of the message body or the date and time that the response was sent.

The message body contains the actual response data, such as HTML, JSON, or XML content.

Some common HTTP status codes include:

Here's an example of a JSON response from the Cat API:

{
    "id": "ErDd1JRRT",
    "url": "https://cdn2.thecatapi.com/images/ErDd1JRRT.jpg",
    "width": 4282,
    "height": 6424,
    "original_filename": "cat1.jpg",
    "pending": 0,
    "approved": 1
}

This is a JSON response from a Cat API request that appears to provide metadata about an image that has been uploaded or retrieved from the API. Here's what each field means:

• id: A unique identifier for the image.
• url: The URL where the image can be accessed.
• width: The width of the image in pixels.
• height: The height of the image in pixels.
• original_filename: The original name of the file that was uploaded.
• pending: A flag indicating whether the image is still being processed by the API.
• approved: A flag indicating whether the image has been approved for public use by the API.

Conclusion

HTTP (Hypertext Transfer Protocol) is a protocol used for exchanging information over the internet. It forms the foundation of the World Wide Web and allows communication between web browsers and servers.

This article is a short introduction to HTTP. If you are interested in learning more, check out these textbook recommendations:

• "HTTP: The Definitive Guide" by David Gourley and Brian Totty - This book is widely regarded as the authoritative guide to HTTP. It covers the protocol in-depth and provides detailed information on its features and implementation.
• "HTTP Pocket Reference" by Clinton Wong - This book provides a concise and portable reference to the HTTP protocol. It covers the essentials of the protocol and is a great resource for developers who need quick access to HTTP information.
• "Web Performance Daybook Volume 2: Techniques and Tips for Optimizing Web Site Performance" edited by Stoyan Stefanov - This book is a collection of essays and articles on web performance, including a section on HTTP optimization. It provides practical advice on how to optimize HTTP for faster and more efficient web performance.

All the code samples for this course are in JavaScript, but the networking concepts you'll learn here apply generally to all coding languages. If you're not familiar with JavaScript yet, you can check out my JS course here.

I've included all the learning material you'll need here in this article, but if you would like a more hands-on experience, you can take the interactive version of this course with coding challenges on Boot.dev here.

I've also published a free video version of this course on the freeCodeCamp YouTube channel:

If you like this video, you can check out my other tutorials on my Boot.dev YouTube channel here.

All that said, let's jump into learning about HTTP!

Table of Contents

1. Why HTTP?

2. What is DNS?

3. What Are URIs?

4. Async/Await

5. Error Handling

6. HTTP Headers

7. What is JSON?

8. HTTP Methods

9. URL Paths and Parameters

10. What is HTTPs?

Why HTTP?

Communicating on the web

Instagram would be pretty terrible if you had to manually copy your photos to your friend's phone when you wanted to share them. Modern applications need to be able to communicate information between devices over the internet.

• Gmail doesn't just store your emails in variables on your computer, it stores them on computers in their data centers.

• You don't lose your Slack messages if you drop your computer in a lake – those messages exist on Slack's servers.

How does web communication work?

When two computers communicate with each other, they need to use the same rules. An English speaker can't communicate verbally with a Japanese speaker, and similarly, two computers need to speak the same language to communicate.

This "language" that computers use is called a protocol. The most popular protocol for web communication is HTTP, which stands for Hypertext Transfer Protocol.

Interacting with a server

In this course, a lot of the code samples will interact with the PokeAPI. It serves data about Pokémon.

Here's some code that retrieves a list of Pokémon from the PokeAPI:

const pokemonResp = await getItemData()

logPokemons(pokemonResp.results)

async function getItemData() {
  const response = await fetch('https://pokeapi.co/api/v2/pokemon/', {
    method: 'GET',
    mode: 'cors',
    headers: {
      'Content-Type': 'application/json'
    }
  })
  return response.json()
}

function logPokemons(pokemons) {
  for (const pokemon of pokemons) {
    console.log(pokemon.name)
  } 
}

When you run this code, you'll notice that none of the data that is logged to the console was generated within our code! That's because the data we retrieved is being sent over the internet from our servers via HTTP. Don't worry, we'll explain more about that later.

HTTP Requests and Responses

At the heart of HTTP is a simple request-response system. The "requesting" computer, also known as the "client", asks another computer for some information. That computer, the "server" sends back a response with the information that was requested.

We'll talk about the specifics of how the "requests" and "responses" are formatted later. For now, just think of it as a simple question-and-answer system.

• Request: "What are the items in the Fantasy Quest game?"

• Response: A list of the items in the Fantasy Quest game

HTTP powers websites

As we discussed, HTTP, or Hypertext Transfer Protocol, is a protocol designed to transfer information between computers.

There are other protocols for communicating over the internet, but HTTP is the most popular and is particularly great for websites and web applications.

Each time you visit a website, your browser is making an HTTP request to that website's server. The server responds with all the text, images, and styling information that your browser needs to render its pretty website.

HTTP URLs

A URL, or Uniform Resource Locator, is essentially the address of another computer, or "server" on the internet. Part of the URL specifies how to reach the server, and part of it tells the server what information we want - but more on that later.

For now, it's important to understand that a URL represents a piece of information on another computer that we want access to. We can get access to it by making a request, and reading the response that the server replies with.

How to Use URLs in HTTP

The http:// at the beginning of a website URL specifies that the http protocol will be used for communication.

Other communication protocols use URLs as well, (hence "Uniform Resource Locator"). That's why we need to be specific when we're making HTTP requests by prefixing the URL with http://

Requests and Responses Review

• A "client" is a computer making an HTTP request

• A "server" is a computer responding to an HTTP request

• A computer can be a client, a server, both, or neither. "Client" and "server" are just words we use to describe what computers are doing within a communication system.

• Clients send requests and receive responses

• Servers receive requests and send responses

JavaScript's Fetch API

In this course, we'll be using JavaScript's built-in fetch API to make HTTP requests.

The fetch() function is made available to us by the JavaScript language running in the browser. All we have to do is provide it with the parameters it requires.

How to Use Fetch

const response = await fetch(url, settings)
const responseData = await response.json()

We'll go in-depth on the various things happening in this standard fetch call later, but let's cover some basics for now.

• response is the data that comes back from the server

• url is the URL we are making a request to

• settings is an object containing some request-specific settings

• The await keyword tells JavaScript to wait until the request comes back from the server before continuing

• response.json() converts the response data from the server into a JavaScript object

See if you can spot the issue with this code snippet:

const pokemonResp = getItemData()

logPokemons(pokemonResp.results)

// the bug is above this line

async function getItemData() {
  const response = await fetch('https://pokeapi.co/api/v2/pokemon/', {
    method: 'GET',
    mode: 'cors',
    headers: {
      'Content-Type': 'application/json'
    }
  })
  return response.json()
}

function logPokemons(pokemons) {
  for (const pokemon of pokemons) {
    console.log(pokemon.name)
  } 
}

Hint: We're not waiting for the data to be sent back across the network.

Web Clients

A web client is a device making requests to a web server. A client can be any type of device but is often something users physically interact with. For example:

• A desktop computer

• A mobile phone

• A tablet

In a website or web application, we call the user's device the "front-end".
A front-end client makes requests to a back-end server.

Web Servers

Up to this point, most of the data you have worked with in your code has simply been generated and stored locally in variables.

While you'll always use variables to store and manipulate data while your program is running, most websites and apps use a web server to store, sort, and serve that data so that it sticks around for longer than a single session, and can be accessed by multiple devices.

Listening and serving data

Similar to how a server at a restaurant brings your food to the table, a web server) serves web resources, such as web pages, images, and other data. The server is turned on and "listening" for inbound requests constantly so that the second it receives a new request, it can send an appropriate response.

The server is the back-end

While the "front-end" of a website or web application is the device the user interacts with, the "back-end" is the server that keeps all the data housed in a central location. If you're still confused, check out this article comparing front-end and back-end development.

A server is just a computer

"Server" is just the name we give to a computer that is taking on the role of serving data across a network connection.

A good server is turned on and available 24 hours a day, 7 days a week. While your laptop can be used as a server, it makes more sense to use a computer in a data center that's designed to be up and running constantly.

What is DNS?

Web Addresses

In the real world, we use addresses to help us find where a friend lives, where a business is located, or where a party is being thrown.

In computing, web clients find other computers over the internet using Internet Protocol or IP addresses.

An IP address is a numerical label that serves two main functions:

1. Location Addressing

2. Network Identification

Domain names and IP Addresses

Each device connected to the internet has a unique IP address. When we browse the internet, the domains we navigate to are all associated with a particular IP address.

For example, this Wikipedia URL points to a page about miniature pigs: https://en.wikipedia.org/wiki/Miniature_pig
The domain portion of the URL is en.wikipedia.org. en.wikipedia.org converts to a specific IP address, and that IP address tells your computer exactly where to communicate with that Wikipedia page.

Cloudflare is a tech company that provides a cool public HTTP server that we can use to look up the IP address of any domain. Take a look at this sample code:

async function fetchIPAddress(domain) {
  const resp = await fetch(`https://cloudflare-dns.com/dns-query?name=${domain}&type=A`, {
    headers: {
      'accept': 'application/dns-json'
    }
  })
  const respObject = await resp.json()
  for (const record of respObject.Answer) {
    return record.data
  }
  return null
}

const domain = 'api.boot.dev'
const ipAddress = await fetchIPAddress(domain)
if (!ipAddress) {
  console.log('something went wrong in fetchIPAddress')
} else {
  console.log(`found IP address for domain ${domain}: ${ipAddress}`)
}

To recap, a "domain name" is part of a URL. It's the part that tells the computer where the server is located on the internet by being converted into a numerical IP address.

We'll cover exactly how an IP address is used by your computer to find a path to the server in a later networking course. For now, it's just important to understand that an IP address is what your computer is using at a lower level to communicate on a network.

Deploying a real website to the internet is actually quite simple. It involves only a couple of steps:

1. Create a server that hosts your website files and connect it to the internet

2. Acquire a domain name

3. Connect the domain name to the IP address of your server

4. Your server is accessible via the internet!

As we discussed, the "domain name" or "hostname" is part of a URL. We'll get to the other parts of a URL later.

For example, the URL https://example.com/path has a hostname of example.com. The https:// and /path portions are not part of the domain name -> IP address mapping that we've been learning about.

Using the URL API in JavaScript

The URL API is built into JavaScript. You can create a new URL object like this:

const urlObj = new URL('https://example.com/example-path')

And then you can extract just the hostname:

const urlObj.hostname

DNS Review

So we've talked about domain names and what their purpose is, but we haven't talked about the system that's used to do that conversion.

DNS, or the "Domain Name System", is the phonebook of the internet. Humans connect to websites through domain names, like Boot.dev.

DNS "resolves" these domain names to find the associated IP addresses so that web clients can load the resources for the specific address.

How does DNS Work?

We'll go into more detail on DNS in a future course, but to give you a simplified idea of how it works, let's introduce ICANN. ICANN is a not-for-profit organization that manages DNS for the entire internet.

Whenever your computer attempts to resolve a domain name, it contacts one of ICANN's "root nameservers" whose address is included in your computer's networking configuration.

From there, that nameserver can gather the domain records for a specific domain name from their distributed DNS database.

If you think of DNS as a phonebook, ICANN is the publisher that keeps the phonebook in print and available.

Subdomains

We learned about how a domain name resolves to an IP address, which is just a computer on a network - often the internet.

A subdomain prefixes a domain name, allowing a domain to route network traffic to many different servers and resources.

For example, the Boot.dev website is hosted on a different computer than our blog. Our blog, found at blog.boot.dev is hosted on our "blog" subdomain.

What are URIs?

We briefly touched on URLs earlier, but now let's dive a little deeper into the subject.

A URI, or Uniform Resource Identifier, is a unique character sequence that identifies a resource that is (almost always) accessed via the internet.

Just like JavaScript has syntax rules, so do URIs. These rules help ensure uniformity so that any program can interpret the meaning of the URI in the same way.

URIs come in two main types:

• URLs

• URNs

We will focus specifically on URLs in this course, but it's important to know that URLs are only one kind of URI.

URLs have quite a few sections, some of which are required, others not.
Let's use the URL API to parse a URL and print all the different parts. We'll learn more about each part later, for now, let's just split and print a URL.

function printURLParts(urlString) {
  const urlObj = new URL(urlString)
  console.log(`protocol: ${urlObj.protocol}`)
  console.log(`username: ${urlObj.username}`)
  console.log(`password: ${urlObj.password}`)
  console.log(`hostname: ${urlObj.hostname}`)
  console.log(`port: ${urlObj.port}`)
  console.log(`pathname: ${urlObj.pathname}`)
  console.log(`search: ${urlObj.search}`)
  console.log(`hash: ${urlObj.hash}`)
}

const fantasyQuestURL = 'http://dragonslayer:pwn3d@fantasyquest.com:8080/maps?sort=rank#id'
printURLParts(fantasyQuestURL)

Further dissecting a URL

There are 8 main parts to a URL, though not all the sections are always present. Each piece plays a specific role in helping clients locate the specified resource.
The 8 sections are:

• The protocol is required

• Usernames and passwords are optional

• A domain is required

• The default port for a given protocol is used if one is not provided

• The default ( / ) path is used if one isn't provided

• A query is optional

• A fragment is optional

Don't get too hung up on memorizing this stuff

Because names for the different sections are often used interchangeably, and because not all the parts of the URL are always present, it can be hard to keep things straight.

Don't worry about memorizing this stuff! Try to just get familiar with these URL concepts from a high level. Like any good developer, you can just look it up again the next time you need to know more.

The Protocol

The "protocol", also referred to as the "scheme", is the first component of a URL. Its purpose is to define the rules by which the data being communicated is displayed, encoded, or formatted.

Some examples of different URL protocols:

• http

• ftp

• mailto

• https

For example:

• http://example.com

• mailto:noreply@fantasyquest.app

Not all schemes require a "//"

The "http" in a URL is always followed by ://. All URLs have the colon, but the // part is only included for schemes that have an authority component.

As you can see above, the mailto scheme doesn't use an authority component, so it doesn't need the slashes.

URL Ports

The port in a URL is a virtual point where network connections are made. Ports are managed by a computer's operating system and are numbered from 0 to 65,535.

Whenever you connect to another computer over a network, you're connecting to a specific port on that computer, which is being listened to by a specific piece of software on that computer. A port can only be used by one program at a time, which is why there are so many possible ports.

The port component of a URL is often not visible when browsing normal sites on the internet, because 99% of the time you're using the default ports for the HTTP and HTTPS schemes: 80 and 443, respectively.

Whenever you aren't using a default port, you need to specify it in the URL. For example, port 8080 is often used by web developers when they're running their server in "test mode" so that they don't use the "production" port "80".

URL Paths

In the early days of the internet, a URL's path often was a reflection of the file path on the server to the resource the client was requesting.

For example, if the website https://exampleblog.com had a web server running within its /home directory, then a request to the https://exampleblog.com/site/index.html URL might expect the index.html file from within the /home/site directory to be returned.

Websites used to be very simple. They were just a collection of text documents stored on a server. A simple piece of server software could handle incoming HTTP requests and respond with the documents according to the path component of the URLs.

These days, it's not always about the filesystem

On many modern web servers, a URL's path isn't a reflection of the server's filesystem hierarchy. Paths in URLs are essentially just another type of parameter that can be passed to the server when making a request.

Conventionally, two different URL paths should denote different resources. For example, different pages on a website, or maybe different data types from a game server.

Query parameters

Query parameters in a URL are not always present. In the context of websites, query parameters are often used for marketing analytics or for changing a variable on the web page. With website URLs, query parameters rarely change which page you're viewing, though they often will change the page's contents.

That said, query parameters can be used for anything the server chooses to use them for, just like the URL's path.

How Google uses query parameters

1. Open a new tab and go to google.com

2. Search for "hello world"

3. Take a look at your current URL. It should start with https://www.google.com/search?q=hello+world

4. Change the URL to say https://www.google.com/search?q=hello+universe

5. Press "enter"

You should see new search results for the query "hello universe". Google chose to use query parameters to represent the value of your search query. It makes sense - each search result page is essentially the same page as far as structure and formatting are concerned - it's just showing you different results based on the search query.

Async/Await

You're probably already familiar with synchronous code, which means code that runs in sequence. Each line of code executes in order, one after the next.

Example of synchronous code:

console.log("I print first");
console.log("I print second");
console.log("I print third");

Asynchronous or async code runs in parallel. That means code further down runs at the same time that a previous line of code is still running. A good way to visualize this is with the JavaScript function setTimeout().

setTimeout accepts a function and a number of milliseconds as inputs. It waits until the number of milliseconds has elapsed, and then it executes the function it was given.

Example of asynchronous code:

jsconsole.log("I print first");
setTimeout(() => console.log("I print third because I'm waiting 100 milliseconds"), 100);
console.log("I print second");

Try altering the waiting times in the async code below to get the messages to print in the proper order:

const craftingCompleteWait = 0
const combiningMaterialsWait = 0
const smeltingIronBarsWait = 0
const shapingIronWait = 0

// Don't touch below this line

setTimeout(() => console.log('Iron Longsword Complete!'), craftingCompleteWait)
setTimeout(() => console.log('Combining Materials...'), combiningMaterialsWait)
setTimeout(() => console.log('Smelting Iron Bars...'), smeltingIronBarsWait)
setTimeout(() => console.log('Shaping Iron...'), shapingIronWait)

console.log('Firing up the forge...')

await sleep(2500)
function sleep(ms) {
  return new Promise((resolve) => setTimeout(resolve, ms))
}

Expected order:

1. Firing up the forge..

2. Smelting Iron Bars...

3. Combining Materials...

4. Shaping Iron...

5. Iron Longsword Complete!

Why do we want async code?

We try to keep most of our code synchronous because it's easier to understand, and therefore often has fewer bugs. But sometimes we need our code to be asynchronous.

For example, whenever you update your user settings on a website, your browser will need to communicate those new settings to the server. The time it takes your HTTP request to physically travel across all the wiring of the internet is usually around 100 milliseconds. It would be a very poor experience if your webpage were to freeze while waiting for the network request to finish. You wouldn't even be able to move the mouse while waiting!

By making network requests asynchronously, we let the webpage execute other code while waiting for the HTTP response to come back. This keeps the user experience snappy and user-friendly.

As a general rule, we should only use async code when we need to for performance reasons. Synchronous code is simpler.

Promises in JavaScript

A Promise in JavaScript is very similar to making a promise in the real world. When we make a promise, we are making a commitment to something.

For example, I promise to explain JavaScript promises to you. My promise to you has 2 potential outcomes: it is either fulfilled, meaning I eventually explained promises to you, or it is rejected, meaning I failed to keep my promise and didn't explain promises.

The Promise Object represents the eventual fulfillment or rejection of our promise and holds the resulting values. In the meantime, while we're waiting for the promise to be fulfilled, our code continues executing.

Promises are the most popular modern way to write asynchronous code in JavaScript.

How to Declare a Promise

Here is an example of a promise that will resolve and return the string "resolved!" or reject and return the string "rejected!" after 1 second.

const promise = new Promise((resolve, reject) => {
  setTimeout(() => {
    if (getRandomBool()) {
      resolve("resolved!")
    } else {
      reject("rejected!")
    }
  }, 1000)
})

function getRandomBool(){
  return Math.random() < .5
}

How to Use a Promise

Now that we've created a promise, how do we use it?

The Promise object has .then and .catch that make it easy to work with. Think of .then as the expected follow-up to a promise, and .catch as the "something went wrong" follow-up.

If a promise resolves, its .then function will execute. If the promise rejects, its .catch method will execute.

Here's an example of using .then and .catch with the promise we made above:

promise.then((message) => {
    console.log(`The promise finally ${message}`)
}).catch((message) => {
    console.log(`The promise finally ${message}`)
})

// prints:
// The promise finally resolved!
// or
// the promise finally rejected!

Why are Promises useful?

Promises are the cleanest (but not the only) way to handle the common scenario where we need to make requests to a server, which is typically done via an HTTP request. In fact, the fetch() function we were using earlier in the course returns a promise!

I/O, or "input/output"

Almost every time you use a promise in JavaScript it will be to handle some form of I/O. I/O, or input/output, refers to when our code needs to interact with systems outside of the (relatively) simple world of local variables and functions.
Common examples of I/O include:

• HTTP requests

• Reading files from the hard drive

• Interacting with a Bluetooth device

Promises help us perform I/O without forcing our entire program to freeze up while we wait for a response.

Promises and the "await" keyword

We have used the await keyword a few times in this course, so it's time we finally understand what's going on under the hood.

The await keyword is used to wait for a promise to resolve. Once it has been resolved, the await expression returns the value of the resolved Promise.

Example with .then callback

promise.then((message) => {
  console.log(`Resolved with ${message}`)
}).

Example of awaiting a promise

const message = await promise
console.log(`Resolved with ${message}`)

The async keyword

While the await keyword can be used in place of .then() to resolve a promise, the async keyword can be used in place of new promise() to create a new promise.

When a function is prefixed with the async keyword, it will automatically return a promise. That promise resolves with the value that your code returns from the function. You can think of async as "wrapping" your function within a promise.

These are equivalent:

New Promise()

function getPromiseForUserData(){
  return new Promise((resolve) => {
    fetchDataFromServerAsync().then(function(user){
      resolve(user)
    })
  })
}

const promise = getPromiseForUserData()

Async

async function getPromiseForUserData(){
  const user = await fetchDataFromServer()
  return user
}

const promise = getPromiseForUserData()

.then() vs await

In the early days of web browsers, promises and the await keyword didn't exist, so the only way to do something asynchronously was to use callbacks.

A "callback function" is a function that you hand to another function. That function then calls your callback later on. The setTimeout function we've used in the past is a good example.

function callbackFunction(){
  console.log("calling back now!")
}
const milliseconds = 1000
setTimeout(callbackFunction, milliseconds)

While even the .then() syntax is generally easier to use than callbacks without the Promise API, the await syntax makes them even easier to use. You should use async and await over .then and new Promise() as a general rule.

To demonstrate, which of these is easier to understand?

fetchUser.then(function(user){
  return fetchLocationForUser(user)
}).then(function(location){
  return fetchServerForLocation(location)
}).then(function(server){
  console.log(`The server is ${server}`)
});

const user = await fetchUser()
const location = await fetchLocationForUser(user)
const server = await fetchServerForLocation(location)
console.log(`The server is ${server}`)

They both do the same thing, but the second example is so much easier to understand! The async and await keywords weren't released until after the .then API, which is why there is still a lot of legacy .then() code out there.

Error Handling

When something goes wrong while a program is running, JavaScript uses the try/catch paradigm for handling those errors. Try/catch is fairly common, and Python uses a similar mechanism.

First, an error is thrown

For example, let's say we try to access a property on an undefined variable. JavaScript will automatically "throw" an error.

const speed = car.speed
// The code crashes with the following error:
// "ReferenceError: car is not defined"

Trying and catching errors

By wrapping that code in a try/catch block, we can handle the case where car is not yet defined.

try {
  const speed = car.speed
} catch (err) {
  console.log(`An error was thrown: ${err}`)
  // the code cleanly logs:
  // "An error was thrown: ReferenceError: car is not defined"
}

Bugs vs Errors

Error handling via try/catch is not the same as debugging. Likewise, errors are not the same as bugs.

• Good code with no bugs can still produce errors that are gracefully handled

• Bugs are, by definition, bits of code that aren't working as intended

What is Debugging?

"Debugging" a program is the process of going through your code to find where it is not behaving as expected. Debugging is a manual process performed by the developer.

Examples of debugging:

• Adding a missing parameter to a function call

• Updating a broken URL that an HTTP call was trying to reach

• Fixing a date-picker component in an app that wasn't displaying properly

What is Error Handling?

"Error handling" is code that can handle expected edge cases in your program. Error handling is an automated process that we design into our production code to protect it from things like weak internet connections, bad user input, or bugs in other people's code that we have to interface with.

Examples of error handling:

• Using a try/catch block to detect an issue with user input

• Using a try/catch block to gracefully fail when no internet connection is available

In short, don't use try/catch to try to handle bugs

If your code has a bug, try/catch won't help you. You need to just go find the bug and fix it.

If something out of your control can produce issues in your code, you should use try/catch or other error-handling logic to deal with it.

For example, there could be a prompt in a game for users to type in a new character name, but we don't want them to use punctuation. Validating their input and displaying an error message if something is wrong with it would be a form of "error handling".

async/await makes error handling easier

try and catch are the standard way to handle errors in JavaScript, the trouble is, the original Promise API with .then didn't allow us to make use of try and catch blocks.

Luckily, the async and await keywords do allow it - yet another reason to prefer the newer syntax.

.catch() callback on promises

The .catch() method works similarly to the .then() method, but it fires when a promise is rejected instead of resolved.

Example with .then and .catch callbacks

fetchUser().then(function(user){
  console.log(`user fetched: ${user}`)
}).catch(function(err){
  console.log(`an error was thrown: ${err}`)
});

Example of awaiting a promise

try {
  const user = await fetchUser()
  console.log(`user fetched: ${user}`)
} catch (err) {
  console.log(`an error was thrown: ${err}`)
}

As you can see, the async/await version looks just like normal try/catch JavaScript.

HTTP Headers

An HTTP header allows clients and servers to pass additional information with each request or response. Headers are just case-insensitive key-value pairs that pass additional metadata about the request or response.

HTTP requests from a web browser carry with them many headers, including but not limited to:

• The type of client (for example Google Chrome)

• The Operating system (for example Windows)

• The preferred language (for example US English)

As developers, we can also define custom headers in each request.

Headers API

The Headers API allows us to perform various actions on our request and response headers such as retrieving, setting, and removing them. We can access the headers object through the Request.headers and Response.headers properties.

How to Use the Browser's Developer Tools

Modern web browsers offer developers a powerful set of developer tools. The Developer Tools are a front-end web developer's best friend. For example, using the dev tools you can:

• View the web page's JavaScript console output

• Inspect the page's HTML, CSS, and JavaScript code

• View network requests and responses, along with their headers

The method for accessing dev tools varies from browser to browser. If you're on Chrome, you can just right-click anywhere within a web page and click the "inspect" option. Follow this link for more info on how to access dev tools.

The network tab

While all of the tabs within the dev tools are very useful, we will be focusing specifically on the Network tab in this chapter so we can play with HTTP headers.

The Network tab monitors your browser's network activity and records all of the requests and responses the browser is making, including how long each of those requests and responses takes to fully process.

If you navigate to the Network tab and don't see any requests appear, try refreshing the page.

Why are headers useful?

Headers are useful for several reasons, from design to security. But most often headers are used as metadata or data about the request.

So, for example, let's say we wanted to ask for a player's level from a game's server. We need to send that player's ID to the server so it knows which player to send back the information for. That ID is my request, it's not information about my request.

A good example of a use case for headers is authentication. Often times a user's credentials are included in request headers. Credentials don't have much to do with the request itself, but simply authorize the requester to be allowed to make the request in question.

What is JSON?

JavaScript Object Notation, or JSON, is a standard for representing structured data based on JavaScript's object syntax.

JSON is commonly used to transmit data in web apps using HTTP. The HTTP fetch() requests we have been using in this course have been returning data as JSON data.

JSON Syntax

Because we already understand what JavaScript objects look like, understanding JSON is easy. JSON is just a stringified JavaScript object. The following is valid JSON data:

{
    "movies": [
        {
            "id": 1,
            "genre": "Action",
            "title": "Iron Man",
            "director": "Jon Favreau"
        },
        {
            "id": 2,
            "genre": "Action",
            "title": "The Avengers",
            "director": "Joss Whedon"
        }
    ]
}

How to Parse HTTP Responses as JSON

JavaScript provides us with some easy tools to help us work with JSON. After making an HTTP request with the fetch() API, we get a Response object. That response object offers us some methods that help us interact with the response.

One such method is the .json() method. The .json() method takes the response stream returned by a fetch request and returns a Promise that resolves into a JavaScript object parsed from the JSON body of the HTTP response.

const resp = await fetch(...)
const javascriptObjectResponse = await resp.json()

It's important to note that the result of the .json() method is NOT JSON. It is the result of taking JSON data from the HTTP response body and parsing that input into a JavaScript Object.

JSON Review

JSON is a stringified representation of a JavaScript object, which makes it perfect for saving to a file or sending in an HTTP request.

Remember, an actual JavaScript object is something that exists only within your program's variables. If we want to send an object outside our program, for example, across the internet in an HTTP request, we need to convert it to JSON first.

It's not just used in JavaScript

Just because JSON is called JavaScript Object Notation doesn't mean it's only used by JavaScript! JSON is a common standard that is recognized and supported by every major programming language.

For example, even though Boot.dev's backend API is written in Go, we still use JSON as the communication format between the front-end and backend.

By the way, this course has been about interacting with back-end servers from a front-end perspective. But if you're curious about how you can become a back-end engineer, check out this guide I've put together. For reference, it takes most people between 6-18 months to learn enough to get their first back-end job.

Common JSON use-cases

• In HTTP request and response bodies

• As formats for text files. .json files are often used as configuration files.

• In NoSQL databases like MongoDB, ElasticSearch, and Firestore

How to Pronounce JSON

I pronounce it "Jay-sawn", but I've also heard people pronounce it "Jason", like the name.

How to Send JSON

JSON isn't just something we get from the server, we can also send JSON data.
In JavaScript, two of the main methods we have access to are JSON.parse(), and JSON.stringify().

JSON.stringify()

JSON.stringify() is particularly useful for sending JSON.

As you may expect, the JSON stringify() method does the opposite of parse. It takes a JavaScript object or value as input and converts it into a string. This is useful when we need to serialize the objects into strings to send them to our server or store them in a database.

Here's a snippet of code that sends a JSON payload to a remote server:

async function sendPayload(data, headers) {
  const response = await fetch(url, {
    method: 'POST',
    mode: 'cors',
    headers: headers,
    body: JSON.stringify(data)
  })
  return response.json()
}

How to Parse JSON

The JSON.parse() method takes a JSON string as input and constructs the JavaScript value/object described by the string. This allows us to work with the JSON as a normal JavaScript object.

Seeing as JSON objects have a tree-like structure, it can be helpful to know how to traverse them recursively if needs be.

const json = '{"title": "Avengers Endgame", "Rating":4.7, "inTheaters":false}';
const obj = JSON.parse(json)

console.log(obj.title)
// Avengers Endgame

XML

We can't talk about JSON without mentioning XML. Extensible Markup Language, or XML is a text-based format for representing structured information, just like JSON - it just looks a bit different.

XML is a markup language like HTML, but it's more generalized in that it does not use predefined tags. Just like how in a JSON object keys can be called anything, XML tags can also have any name.

<root>
  <id>1</id>
  <genre>Action</genre>
  <title>Iron Man</title>
  <director>Jon Favreau</director>
</root>

The same data in JSON form:

{
  "id": "1",
  "genre": "Action",
  "title": "Iron Man",
  "director": "Jon Favreau"
}

Why use XML?

XML and JSON both accomplish similar tasks, so which should you use?

XML used to be used for the same things that today JSON is used for. Configuration files, HTTP bodies, and other data-transfer use cases can work just fine using JSON or XML. Here's my advice: generally speaking, if JSON works, you should favor it over XML these days. JSON is lighter-weight, easier to read, and has better support in most modern programming languages.

There are some cases where XML might still be the better, or maybe even the necessary choice, but those cases will be rare.

HTTP Methods

HTTP defines a set of methods that we use every time we make a request. We have used some of these methods in previous exercises, but it's time we dive into them and understand the differences and use cases behind the different methods.

The GET method

The GET method is used to "get" a representation of a specified resource. You are not taking the data away from the server, but rather getting a representation, or copy, of the resource in its current state.

A get request is considered a safe method to call multiple times because it doesn't alter the state of the server.

How to Make a GET Request using the Fetch API

The fetch() method accepts an optional init object parameter as its second argument that we can use to define things like:

• method: The HTTP method of the request, like GET.

• headers: The headers to send.

• mode: Used for security, we'll talk about this in future courses

• body: The body of the request. Often encoded as JSON.

Example GET request using fetch:

await fetch(url, {
  method: 'GET',
  mode: 'cors',
  headers: {
    'sec-ch-ua-platform': 'macOS'
  }
})

Why do we use HTTP methods?

As we touched on before, the primary purpose of HTTP methods is to indicate to the server what we want to do with the resource we're trying to interact with.

At the end of the day, an HTTP method is just a string, like GET, POST, PUT, or DELETE. But by convention, backend developers almost always write their server code so that the methods correspond with different "CRUD" actions.

The "CRUD" actions are:

• Create

• Read

• Update

• Delete

The bulk of the logic in most web applications is "CRUD" logic. The web interface allows users to create, read, update and delete various resources.

Think of a social media site - users are basically creating, reading, updating and deleting their social posts. They are also creating, reading, updating and deleting their user accounts. It's CRUD all the way down!

As it happens, the 4 most common HTTP methods map nicely to the CRUD actions:

• POST = create

• GET = read

• PUT = update

• DELETE = delete

POST Requests

An HTTP POST request sends data to a server, typically to create a new resource. The body of the request is the payload that is being sent to the server with the request. Its type is indicated by the Content-Type header.

How to Add a body

The body of the request is the payload that is being sent to the server with the request. Its type is indicated by the Content-Type header - for us, that's going to be JSON.

POST requests are generally not safe methods to call multiple times, because it alters the state of the server. You wouldn't want to accidentally create 2 accounts for the same user, for example.

await fetch(url, {
  method: 'POST',
  mode: 'cors',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify(data)
})

HTTP Status Codes

Now that we understand how to write HTTP requests from scratch, we need to learn how to ensure that the server is doing what we want.

Earlier in the course, we learned about how to access the browser's developer tools and use those tools to inspect HTTP requests. We can use that same process to check on the requests we are making and verify what they are doing so we can address potential problems.

When looking at requests, we can check on the Status Code of the request to get some information if the request was successful or not.

• 100-199: Informational responses. These are very rare.

• 200-299: Successful responses. Hopefully, most responses are 200's!

• 300-399: Redirection messages. These are typically invisible because the browser or HTTP client will automatically do the redirect.

• 400-499: Client errors. You'll see these often, especially when trying to debug a client application

• 500-599: Server errors. You'll see these sometimes, usually only if there is a bug on the server.

Here are some of the most common status codes, but you can see a full list here if you're interested.

• 200 - OK. This is by far the most common code, it just means that everything worked as expected.

• 201 - Created. This means that a resource was created successfully. Typically in response to a POST request.

• 301 - Moved permanently. This means the resource was moved to a new place, and the response will include where that new place is. Websites often use 301 redirects when they change their domain name, for example.

• 400 - Bad request. A general error indicating the client made a mistake in their request.

• 403 - Unauthorized. This means the client doesn't have the correct permissions. Maybe they didn't include a required authorization header, for example.

• 404 - Not found. You'll see this on websites quite often. It just means the resource doesn't exist.

• 500 - Internal server error. This means something went wrong on the server, likely a bug on their end.

You don't need to memorize them

You need to know the basics, like "2XX is good", "4XX is a client error", and "5XX is a server error". That said, you don't need to memorize all the codes, they're easy to look up.

Let's check some status codes!

The .status property on a Response object will give you the code. Here's an example:

async function getStatusCode(url, headers) {
  const response = await fetch(url, {
    method: 'GET',
    mode: 'cors',
    headers: headers
  })
  return response.status
}

PUT Method

The HTTP PUT method creates a new resource or replaces a representation of the target resource with the contents of the request's body. In short, it updates a resource's properties.

await fetch(url, {
   method: 'PUT',
   mode: 'cors',
   headers: {
   'Content-Type': 'application/json'
   },
   body: JSON.stringify(data)
})

POST vs PUT

You may be thinking PUT is similar to POST or PATCH, and frankly, you'd be right. The main difference is that PUT is meant to be idempotent, meaning multiple identical PUT requests should have the same effect on the server.

In contrast, several identical POST requests would have additional side effects, such as creating multiple copies of the resource.

HTTP Patch vs PUT

You may encounter PATCH methods from time to time. While it is not nearly as common as the other methods, like PUT, it's important to know about it and what it does. The PATCH method is intended to partially modify a resource.

Long story short, PATCH isn't nearly as popular as PUT, and many servers, even if they allow partial updates, will still just use the PUT method for that.

HTTP Delete

The DELETE method does exactly as you would expect: it's conventionally used to delete a specified resource.

// This deletes the location with ID: 52fdfc07-2182-454f-963f-5f0f9a621d72
const url = 'https://example-api.com/locations/52fdfc07-2182-454f-963f-5f0f9a621d72'

await fetch(url, {
  method: 'DELETE',
  mode: 'cors'
})

URL Paths and Parameters

The URL Path comes right after the domain (or port if one is provided) in a URL string.

In this URL, the path is /root/next: http://testdomain.com/root/next.

What paths meant in the early internet

In the early days of the internet, and sometimes still today, many web servers simply served raw files from the server's file system.

For example, if I wanted you to be able to access some text documents, I could start a web server in my documents directory. If you made a request to my server, you would be able to access different documents by using the path that matched my local file structure.

If I had a file in my local /documents/hello.txt, you could access it by making a GET request to http://example.com/documents/hello.txt.

How paths are used today

Most modern web servers don't use that simple mapping of URL path -> file path. Technically, a URL path is just a string that the web server can do what it wants with, and modern websites take advantage of that flexibility.

Some common examples of what paths are used for include:

• The hierarchy of pages on a website, whether or not that reflects a server's file structure

• Parameters being passed into an HTTP request, like an ID of a resource

• The version of the API

• The type of resource being requested

RESTful APIs

Representational State Transfer, or REST, is a popular convention that HTTP servers follow. Not all HTTP APIs are "REST APIs", or "RESTful", but it is very common.

RESTful servers follow a loose set of rules that makes it easy to build reliable and predictable web APIs. REST is more or less a set of conventions about how HTTP should be used.

Separate and agnostic

The big idea behind REST is that resources are transferred via well-recognized, language-agnostic client/server interactions.

A RESTful style means the implementation of the client and server can be done independently of one another, as long as some simple standards, like the names of the available resources, have been established.

Stateless

A RESTful architecture is stateless. This means that the server does not need to know what state the client is in, nor does the client need to know what state the server is in.

Statelessness in REST is enforced by interacting with resources instead of commands. Keep in mind, this doesn't mean the applications are stateless - on the contrary, what would "updating a resource" even mean if the server wasn't keeping track of its state?

Paths in REST

In a RESTful API, the last section of the path of a URL should specify which resource is being accessed. Then, as we talked about in the "methods" section, depending on whether the request is a GET, POST, PUT or DELETE, the resource is read, created, updated, or deleted.

For example, in the PokeAPI:

• https://pokeapi.co/api/v2/pokemon/

• https://pokeapi.co/api/v2/location/

The first part of the path specifies that we're interacting with an API rather than a website. The next part specifies the version, in this case, version 2, or v2.

Finally, the last part denotes which resource is being accessed, be it a location or pokemon.

URL Query Parameters

A URL's query parameters appear next in the URL structure but are not always present - they're optional. For example:

https://www.google.com/search?q=boot.dev

q=boot.dev is a query parameter. Like headers, query parameters are key / value pairs. In this case, q is the key and boot.dev is the value.

The Documentation of an HTTP Server

You may be wondering:

How the heck am I supposed to memorize how all these different servers work???

The good news is that you don't need to. When you work with a backend server, it's the responsibility of that server's developers to provide you with instructions, or documentation that explains how to interact with it.

For example, the documentation should tell you:

• The domain of the server

• The resources you can interact with (HTTP paths)

• The supported query parameters

• The supported HTTP methods

• Anything else you'll need to know to work with the server

The server has control

As we mentioned earlier, the server has complete control over how the path in a URL is interpreted and used in a request. The same goes for query parameters.

Not all servers support query parameters for every type of request, it just depends, so you'll need to consult the docs.

Multiple Query Parameters

We mentioned that query parameters are key/value pairs - that means we can have multiple pairs.

http://example.com?firstName=lane&lastName=wagner

In the example above:

• firstName = lane

• lastName = wagner

The ? separates the query parameters from the rest of the URL. The & is then used to separate every pair of query parameters after that.

For example, make this request to limit the number of Pokémon returned from the PokeAPI to 2:

https://pokeapi.co/api/v2/location/?limit=2

What is HTTPs?

Hypertext Transfer Protocol Secure or HTTPS is an extension of the HTTP protocol. HTTPS secures the data transfer between client and server by encrypting all of the communication.

HTTPS allows a client to safely share sensitive information with the server through an HTTP request, such as credit card information, passwords, or bank account numbers.

HTTPS requires that the client use SSL or TLS to protect requests and traffic by encrypting the information in the request. HTTPS is just HTTP with extra security.

HTTP vs HTTPS

HTTPS keeps your messages private, but not your identity

We won't cover how encryption works in this course, but we will in later courses. For now, it's important to note that while HTTPS encrypts what you are saying, it doesn't necessarily protect who you are. Tools like VPNs are needed for remaining anonymous online.

HTTPS ensures that you're talking to the right person (or server)

In addition to encrypting the information within a request, HTTPS uses digital signatures to prove that you're communicating with the server that you think you are.

If a hacker were to intercept an HTTPS request by tapping into a network cable, they wouldn't be able to successfully pretend they are your bank's web server.

Assuming that a server supports HTTPs, you use it by simply changing the protocol on your request URL: https://boot.dev

Want to put what you've learned into practice with a project?

Check out this project guide where you'll build a web crawler in JavaScript from scratch. It will have you using the Fetch API and parsing JSON data like a pro! You don't need to build the project, but it's a great way to practice what you're learned.

Congratulations on making it to the end!

If you're interested in doing the interactive coding assignments and quizzes for this course you can check out the Learn HTTP course over on Boot.dev.

This course is a part of my full back-end developer career path, made up of other courses and projects if you're interested in checking those out.

If you want to see the other content I'm creating related to web development, check out some of my links below:

• Lane on Twitter

• Lane on YouTube

• Lane's Personal Site

We just published a full course on the freeCodeCamp.org YouTube channel that will help you master the HTTP networking protocol by completing over 80 coding exercises and quizzes in JavaScript. The course is designed to help students understand the various concepts of HTTP networking through hands-on learning.

Lane Wagner created this course. He is a senior back end engineer and is the creator of boot.dev where he has published many interactive courses.

Starting from the basics, students watching this course will learn about:

• why HTTP is important,
• how DNS (Domain Name System) works,
• the difference between URIs (Uniform Resource Identifiers) and URLs (Uniform Resource Locators),
• how HTTP headers work,
• how to write and use JSON (JavaScript Object Notation),
• the difference between various HTTP methods,
• how URL paths are used in HTTP communication, and
• implementing security using HTTPS.

To help students put their knowledge into practice, the course includes a project where they will build a real web crawler using Node.js. The project will cover the following topics: setting up a development environment, creating a "Hello World" program, normalizing URLs, extracting URLs from HTML, using the Fetch API, recursively crawling the web, and printing an SEO report.

By the end of this video course, students will have a solid understanding of HTTP networking and will be able to put their skills into practice by building a real web crawler.

In conclusion, if you're looking to deepen your knowledge of HTTP networking and build practical skills, this video course is an excellent choice. With over 80 coding exercises and quizzes, students will get a hands-on learning experience that will help them understand the various concepts of HTTP networking. Sign up now and start your journey to mastering HTTP networking.

Watch the full course on the freeCodeCamp.org YouTube channel (5-hour watch).

One of the five popular HTTP methods for making requests and interacting with your servers is the POST method, which you can use to send data to a server.

In this article, you will learn the various methods that you can use to send an HTTP POST request to your back-end server in JavaScript. We'll send GET requests to the free JSON Placeholder todos API for this guide.

There are two built-in JavaScript methods for making an HTTP POST request that don't require the installation of a library or the use of a CDN. These methods are the FetchAPI, based on JavaScript promises, and XMLHttpRequest, based on callbacks.

There are other methods, such as Axios and jQuery, that you will also learn how to use.

How to Send a POST Request with the Fetch API

The FetchAPI is a built-in method that takes in one compulsory parameter: the endpoint (API URL). While the other parameters may not be necessary when making a GET request, they are very useful for the POST HTTP request.

The second parameter is used to define the body (data to be sent) and type of request to be sent, while the third parameter is the header that specifies the type of data you will send, for example JSON.

fetch("https://jsonplaceholder.typicode.com/todos", {
  method: "POST",
  body: JSON.stringify({
    userId: 1,
    title: "Fix my bugs",
    completed: false
  }),
  headers: {
    "Content-type": "application/json; charset=UTF-8"
  }
});

In the code above, the body holds the data to be sent to the server and added to the JSONPlaceholder todos API. Also, the headers hold the type of content you want to send to the server, which in this case is JSON data.

Note: It is always best to serialize your data before sending it to a web server or API using the JSON.stringify() method. This will help convert and ensure your JSON data is in string format.

The Fetch API is based on JavaScript promises, so you need to use the .then method to access the promise or response returned.

fetch("https://jsonplaceholder.typicode.com/todos", {
  method: "POST",
  body: JSON.stringify({
    userId: 1,
    title: "Fix my bugs",
    completed: false
  }),
  headers: {
    "Content-type": "application/json; charset=UTF-8"
  }
})
  .then((response) => response.json())
  .then((json) => console.log(json));

If this is successful, it will return the new JSON data you send to the server.

How to Send a POST Request with XMLHttpRequest

Like the Fetch API, XMLHttpRequest is also in-built and has existed much longer than the Fetch API. This means that almost all modern browsers have a built-in XMLHttpRequest object to request data from a server.

You will start by creating a new XMLHttpRequest object stored in a variable called xhr. This is important as it gives you access to all its objects using the variable.

For example, you can then open a connection with .open(), which is used to specify the request type and endpoint (the URL of the server). As you did for the FetchAPI, you will specify the type of data using the setRequestHeader method.

const xhr = new XMLHttpRequest();
xhr.open("POST", "https://jsonplaceholder.typicode.com/todos");
xhr.setRequestHeader("Content-Type", "application/json; charset=UTF-8")

The next step is to create the data to be sent to the server. Make sure you serialize the data and then store it in a variable that you'll send with the .send() method after making some checks with the .onload method.

const body = JSON.stringify({
  userId: 1,
  title: "Fix my bugs",
  completed: false
});
xhr.onload = () => {
  if (xhr.readyState == 4 && xhr.status == 201) {
    console.log(JSON.parse(xhr.responseText));
  } else {
    console.log(`Error: ${xhr.status}`);
  }
};
xhr.send(body);

When you put the code together, it will look like this and return the JSON data you send to the server:

const xhr = new XMLHttpRequest();
xhr.open("POST", "https://jsonplaceholder.typicode.com/todos");
xhr.setRequestHeader("Content-Type", "application/json; charset=UTF-8");
const body = JSON.stringify({
  userId: 1,
  title: "Fix my bugs",
  completed: false
});
xhr.onload = () => {
  if (xhr.readyState == 4 && xhr.status == 201) {
    console.log(JSON.parse(xhr.responseText));
  } else {
    console.log(`Error: ${xhr.status}`);
  }
};
xhr.send(body);

The major difference between the Fetch API and XMLHttpRequest method is that the Fetch API has a better syntax that is easier to read and understand.

At this point, you have learned how to use the two JavaScript inbuilt methods to send POST HTTP requests. Let’s now learn how to use Axios and jQuery.

How to Send a POST Request with Axios

Axios is an HTTP client library. This library is based on promises that simplify sending asynchronous HTTP requests to REST endpoints. We will send a GET request to the JSONPlaceholder Posts API endpoint.

Unlike the Fetch API and XMLHttpRequest, Axios is not built-in. This means you need to install Axios in your JavaScript project.

To install a dependency into your JavaScript project, you will first initialize a new npm project by running the following command in your terminal:

$ npm init -y

And now, you can install Axios in your project by running the following command:

$ npm install axios

Once Axios is successfully installed, you can send your POST request. This is quite similar to the Fetch API request.

You will pass the API endpoint/URL to the post() method, which will return a promise. You can then handle the promise with the .then() and .catch() methods.

axios.post("https://jsonplaceholder.typicode.com/todos", {
    userId: 1,
    title: "Fix my bugs",
    completed: false
  })
  .then((response) => console.log(response.data))
  .then((error) => console.log(error));

Note: Axios will automatically serialize the object to JSON and set the Content-Type header to 'application/json' for you.

This will return the new data sent to the server.

How to Send a POST Request with jQuery

Making an HTTP request in jQuery is similar to the Fetch API and Axios, but jQuery is not in-built. So you will first have to install or use its CDN in your project:

<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.6.2/jquery.min.js" integrity="sha512-tWHlutFnuG0C6nQRlpvrEhE4QpkG1nn2MOUMWmUeRePl4e3Aki0VB6W1v3oLjFtd0hVOtRQ9PHpSfN6u6/QXkQ==" crossorigin="anonymous" referrerpolicy="no-referrer"></script>

With jQuery, you can access the POST method $.post(), which takes in three parameters: the API endpoint/URL, the data to be sent to the server, and a callback function that runs when the request is successful.

const body = {
  userId: 1,
  title: "Fix my bugs",
  completed: false
};
$.post("https://jsonplaceholder.typicode.com/todos", body, (data, status) => {
  console.log(data);
});

Note: You can access the request's data and status in the callback function.

You can check this similar article on how to make an HTTP GET request in JavaScript.

Wrapping Up

In this article, you have learned how to send an HTTP POST request in JavaScript. You might now begin to think — which method should I use?

You can choose between the Fetch API and Axios if it's a new project. Also, if you want to consume basic APIs for a small project, Axios is optional because it demands installing a library.

Have fun coding!

You can access over 150 of my articles by visiting my website. You can also use the search field to see if I've written a specific article.

This interaction between your frontend application and the backend server is possible through HTTP requests.

There are five popular HTTP methods you can use to make requests and interact with your servers. One HTTP method is the GET method, which can retrieve data from your server.

This article will teach you how to request data from your servers by making a GET request. You will learn the popular methods that exist currently and some other alternative methods.

For this guide, we'll retrieve posts from the free JSON Placeholder posts API.

There are two popular methods you can easily use to make HTTP requests in JavaScript. These are the Fetch API and Axios.

How to Make a GET Request with the Fetch API

The Fetch API is a built-in JavaScript method for retrieving resources and interacting with your backend server or an API endpoint. Fetch API is built-in and does not require installation into your project.

Fetch API accepts one mandatory argument: the API endpoint/URL. This method also accepts an option argument, which is an optional object when making a GET request because it is the default request.

  fetch(url, {
      method: "GET" // default, so we can ignore
  })

Let’s create a GET request to get a post from the JSON Placeholder posts API.

fetch("https://jsonplaceholder.typicode.com/posts/1")
  .then((response) => response.json())
  .then((json) => console.log(json));

This will return a single post which you can now store in a variable and use within your project.

Note: For other methods, such as POST and DELETE, you need to attach the method to the options array.

How to Make a GET Request with Axios

Axios is an HTTP client library. This library is based on promises that simplify sending asynchronous HTTP requests to REST endpoints. We will send a GET request to the JSONPlaceholder Posts API endpoint.

Axios, unlike the Fetch API, is not built-in. This means you need to install Axios into your JavaScript project.

To install a dependency into your JavaScript project, you will first initialize a new npm project by running the following command in your terminal:

$ npm init -y

And now you can install Axios to your project by running the following command:

$ npm install axios

Once Axios is successfully installed, you can create your GET request. This is quite similar to the Fetch API request. You will pass the API endpoint/URL to the get() method, which will return a promise. You can then handle the promise with the .then() and .catch() methods.

axios.get("https://jsonplaceholder.typicode.com/posts/1")
.then((response) => console.log(response.data))
.catch((error) => console.log(error));

Note: The major difference is that, for Fetch API, you first convert the data to JSON, while Axios returns your data directly as JSON data.

At this point, you have learned how to make a GET HTTP request with Fetch API and Axios. But there are some other methods that still exist. Some of these methods are XMLHttpRequest and jQuery.

How to Make a GET Request with XMLHttpRequest

You can use the XMLHttpRequest object to interact with servers. This method can request data from a web server’s API endpoint/URL without doing a full page refresh.

Note: All modern browsers have a built-in XMLHttpRequest object to request data from a server.

Let’s perform the same request with the XMLHttpRequest by creating a new XMLHttpRequest object. You will then open a connection by specifying the request type and endpoint (the URL of the server), then you'll send the request, and finally listen to the server’s response.

const xhr = new XMLHttpRequest();
xhr.open("GET", "https://jsonplaceholder.typicode.com/posts/1");
xhr.send();
xhr.responseType = "json";
xhr.onload = () => {
  if (xhr.readyState == 4 && xhr.status == 200) {
    console.log(xhr.response);
  } else {
    console.log(`Error: ${xhr.status}`);
  }
};

In the above code, a new XMLHttpRequest object is created and stored in a variable called xhr. You can now access all its objects using the variable, such as the .open() method, when you specify the request type (GET) and the endpoint/URL where you want to request data.

Another method you will use is .send(), which sends the request to the server. You can also specify the format in which the data will be returned using the responseType method. At this point, the GET request is sent, and all you have to do is listen to its response using the onload event listener.

If the client's state is done (4), and the status code is successful (200), then the data will be logged to the console. Otherwise, an error message showing the error status will appear.

How to Make a GET Request with jQuery

Making HTTP requests in jQuery is relatively straightforward and similar to the Fetch API and Axios. To make a GET request, you will first install jQuery or make use of its CDN in your project:

<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.6.2/jquery.min.js" integrity="sha512-tWHlutFnuG0C6nQRlpvrEhE4QpkG1nn2MOUMWmUeRePl4e3Aki0VB6W1v3oLjFtd0hVOtRQ9PHpSfN6u6/QXkQ==" crossorigin="anonymous" referrerpolicy="no-referrer"></script>

With jQuery, you can access the GET method $.get(), which takes in two parameters, the API endpoint/URL and a callback function that runs when the request is successful.

$.get("https://jsonplaceholder.typicode.com/posts/1", (data, status) => {
  console.log(data);
});

Note: In the callback function, you have access to the request's data and the request's status.

You can also use the jQuery AJAX Method, which is quite different and can be used to make asynchronous requests:

$.ajax({
  url: "https://jsonplaceholder.typicode.com/posts/1",
  type: "GET",
  success: function (data) {
    console.log(data);
  }
});

Wrapping Up

In this article, you have learned how to make the HTTP GET request in JavaScript. You might now begin to think — which method should I use?

If it’s a new project, you can choose between the Fetch API and Axios. Also, if you want to consume basic APIs for a small project, there is no need to use Axios, which demands installing a library.

Have fun coding!

We interact with HTTP and HTTPS a lot in our day-to-day lives, but many people don't know the difference.

Most computer users just see that the browser is telling them their application is not safe and that a hacker might want to steal their important information. This leads to users running away faster than Usain Bolt's current record.

But this is avoidable. That is where HTTPS comes in and replaces HTTP. And we are going to discuss that today. :)

Here's What We'll Cover:

1. What is HTTP?
2. How HTTP works
3. Features of HTTP
4. How to know if a site is not secure
5. Are all HTTP websites insecure?
6. What is HTTPS?
7. How HTTPS works
8. Features of HTTPS
9. How encryption works
10. How to know if a site is secure
11. What is an SSL certificate?
12. How does SSL work?
13. How can I get SSL for my website?
14. Where can I get an SSL certificate?
15. Can I get an SSL certificate for free?
16. The main differences between HTTPS and HTTP
17. Conclusion

What is HTTP?

Hyper Text Transfer Protocol, or HTTP, is a communication method between your browser and the site you want to visit (web server).

This allows you to get the information that you need from the server on your browser.

A good way to understand HTTP and HTTPS is by using an analogy. We know that browsers and servers communicate using HTTP. HTTP is usually in plain text. Many people around the world speak English. If a hacker who knows English hacks into your computer, they can easily see any password you input.

Here in Kenya, in my mother tongue, we speak Turkana. If you don't speak the language and you come to Kenya and find two Turkanas speaking, you may not understand what they are saying.

That's the beauty of HTTPS. It is encrypted so that the hacker hopefully doesn't understand the communication between the browser and the server.


If I was to go to http://www.google.com, I would expect to see Google's default page.


The client, which in most cases is the web browser, sends a message which in computer terms is a request. Then the server will give back an answer, which is the response.

HTTP is very useful in sending HTML documents as well as images and videos to the web browser for the user to see. It is also used to send data to the server in HTML forms.


How HTTP Works

HTTP sends data through plain text. For example, if you were to access your bank's web page and they are using HTTP, a hacker may be able to access it and read any information that you send.

This is where HTTPS comes in. Many companies have implemented HTTPS to be able to allow their users to send data securely. We'll discuss this further below.

Features of HTTP

• Plain text. Initially when HTTP was developed, developers had one thing in mind: to serve only text documents. Now, HTTP is used in more ways than it was initially intended.

• Layer 7 protocol. HTTP is a layer 7 protocol in the OSI Model of networking. Layer 7 is the application layer. This layer is the top-most layer in the OSI model. The other layers include the physical, data link, network, transport, session, and presentation layer. To learn more about the OSI model, you can check out this free video on freeCodeCamp's YouTube channel by Brian Ferrill about how the internet works. There are more cookies in the jar other than the OSI model. Computer Networking Course - Network Engineering [CompTIA Network+ Exam Prep]

• Insecure. When you send HTTP requests they are sent through plain text. Also, when you get a response, you get it through plain text. This means that anyone who can access the requests and the responses can read them. 

• Light weight. The advantage of HTTP is that it is very lightweight. It is therefore very fast since it doesn't do the encryption stuff to secure the data, like HTTPS does.
• HTTP usually listens on port 80.

How to Know if a Site is Not Secure

When a site is not secure, Chrome will usually send a warning that says Your connection is not private. 

On Chrome, the URL bar will usually show Not Secure in red if a site is not secure. 

Are All HTTP Websites Insecure?

Well, let's look at an example. Imagine you are browsing a meme website, laughing at each one as you scroll by. If it is using HTTP, then you are off the hook. It's not a big deal.

You get bored and decide to go to your bank's site to access your account on your browser. If the site is not using HTTPS, you might as well be serving your account details to a hacker on a silver plate.

So the bottom line is, if you're browsing inconsequential information, HTTP is ok. But if you are dealing with insecure information, HTTP isn't enough.

What is HTTPS?

Hyper Text Transfer Protocol Secure, or HTTPS, is a way that communication can happen SECURELY between your browser and the site you want to visit (web server).

How HTTPS Works

HTTPS makes a secure connection by using a secure protocol that encrypts your data.

For most websites, the best way to have HTTPS is by getting an SSL (Secure Sockets Layer) Certificate or a TLS (Transport Layer Security) certificate.

At the moment, SSL has become advanced enough that it supports TLS. So you don't need to get a TLS certificate.

Features of HTTPS

• Encrypts data. Data encryption happens through the TLS/SSL protocol.
• It is a layer 4 (Transport layer) protocol.
• Key exchanges of public and private keys happen in HTTPS to encypt and decrypt data.
• Compared to HTTP, is it heavier. When encrpytion and decryption happens in HTTPS, it becomes heavier.
• HTTP listens on port 443.

  How Encryption Works


Let's say I type "I am a dev". This text gets encrypted when I click send, and then it gets decrypted on the server side.

The same is also true from the server side. If I get a response from the server, it will first get encrypted, then it will get decrypted on the client side.

How to Know if a Site is Secure

To know that a site is secure, you usually look at the URL bar where you can see a lock. If there is a lock, the connection from the client to the server is secure.


When you click on the lock icon, it tells you more about the secure connection.


What is an SSL Certificate?

An SSL certificate is a little file that tells browsers that your website –for example, freecodecamp.org – is who it says it is, and that it is reliable.

In order to authenticate, the certificate is able to confirm to the client (user) that the server they are connecting to is the one that manages that domain. All this is to keep the user safe from security issues such as domain spoofing.

It contains a public key and tells you who the owner of the website is that you are trying to connect to. If a website doesn't have an SSL certificate, it cannot be encrypted with TLS.

You can personally create your own SSL certificate (also known as a self-signed certificate), if you are the website owner. The problem with this approach is that browsers like Chrome don't trust these certificates. They prefer trusting certificates that are issued by a certificate authority.

How Does SSL Encryption Work?

There are two types of SSL encryption, asymmetric and symmetric. The combination of asymmetric and symmetric is what makes SSL Encryption work. Let's look at them below to learn more.

What is asymmetric encryption?

In Asymmetric encryption, you have two keys. These are:

1. Public key.
2. Private key.


The client/user/browser gives the public key to the server with which they are communicating. Then, the encyption happens with the help of the public key, and the decryption happens with the help of the server's private key.

The private key can only be found on that particular server. No one else has it. This shows you why asymmetric encryption is stronger and tougher to hack, because it has two different keys, the private and public key. The two keys work together to make sure the data is more secure.

This also tells you why the size of this encryption is 1024/2048 bits.

What is symmetric encryption?

In symmetric encryption, it's very simple. You have one key, and that's it. The client uses one key for encryption, and the server uses the same key for decrypting the data.

Symmetric encryption is very light weight. The size is 128/256 bits. But it is a bit easier to hack into as compared to asymmetric. This doesn't mean it is not useful. When we use SSL, we combine Asymmetric and Symmetric to be able to make the communication safer and more secure.


How asymmetric + symmetric encryption work

The combination of both asymmetric and symmetric is now the double-sided wall. 

In the first step, the server will send to the browser the asymmetric public key. As we now know, the asymmetric key has both the public key and the private key. Therefore, the browser will receive the public key.

After this, the browser generates a session key.

Symmetric encryption uses only one single key for both the client and the server. So what will happen is, the browser will generate a local session key. This is a symmetric encryption session key. It will then encrypt it, with the use of the public key which is asymmetric, given in the first step. The locally generated session key will then be combined with the public key, and sent to the server.

The server will then use a private key to decrypt the encrypted session key it has received. In this particular step, the server will use asymmetric private key to decrypt the session key it has received.

Now, once the decryption has happened, the server and the browser will use the session key for communication. The session key will only be used for that specific session.

Let's say you close your browser, and maybe sign in the next day – everything starts all over again. Session keys get created again.

How Can I Get SSL for My Website?

If you are a website owner, you can acquire an SSL certificate from a certificate issuing authority.

You will then need to install the certificate on you web server where your website is hosted. Most of the time, the hosting company where you host your website handles this process for you.

Where Can I Get an SSL Certificate?

There are organizations that issue security certificates. These organizations are called certificate authorities. Some of these certificate authorities include: DigiCert, Comodo, and many others.

Many developers get certificates from these organizations. Since they are the most widely used certificate issuers, browsers usually trust certificates from these organizations.

Can I Get an SSL Certificate for Free?

Cloudflare offers SSL certificates for free. It is one of the first internet security companies to do so.

If you want to get one, you can check it out here.

What is HTTPS Used For?

HTTPS helps a lot with security. Without it, passing sensitive information becomes a big challenge especially if your business requires a secure way of communication.

Sites that accept online payments like ecommerce sites typically require HTTPS. This is to avoid information such as credit card details and login information from being stolen (Source: Tony Messer).

The Main Differences between HTTPS and HTTP

• The encryption layer is enabled in HTTPS while there is no encryption layer in HTTP.
• Your data is protected in HTTPS while in HTTP it is not.
• Your ranking is boosted in Google when you use HTTPS while with HTTP, you don't get any ranking boost.
• You are protected against phishing when you use HTTPS while there is not protection when using HTTP.
• You are compliant with the regulations of the payment industry when you use HTTPS while HTTP is non-compliant.
• Loading HTTPS in the first few seconds may be slower than loading HTTP.
• Getting SSL certificates can cost money while there is no certification costs with HTTP.
• While using HTTPS, you become buddies with Google Chrome. Google Chrome doesn't like HTTP and therefore you will always be getting unsecured site notifications.

Conclusion

HTTP and HTTPS are very important in our day to day lives as developers. The communication between the browser and the server is what fuels much the work we do.

By protecting your users' data as much as you're able so their information doesn't get stolen, you'll gain their trust and provide a better user experience.

See you soon.

For a developer, this error can be hard to resolve because, on many occasions, it doesn’t show what you need to do to fix it.

But if you’re surfing the net as a user and you encounter the error, there could be a hint showing what to do.

In this case, you should wait a bit to make another request. For security reasons, the period of time to wait might not be specified. But if the website proritzes user experience, they'll show you how much time to wait before making another request.

In this article, I will explain what the 429 error means and how a developer might have implemented it. I will also show what you can do to resolve it as an internet user.

What is the 429 Error?

The 429 error is an HTTP status code. It tells you when the use of an internet resource has surpassed the number of requests it can send within a given period of time.

This error might be shown to you in another form like:

• Error 429
• 429 Too many requests
• 429 (Too many requests)

It all depends on how the administrator in charge of the internet resource customizes it.

In the small app I built to show you how rate limiting is implemented in an Express app, this is how I customized the error:

With this error, the administrators in charge of a website or internet resource are telling you they don’t have enough resources to handle the number of requests you are sending over. This is called “rate limiting”.

What Causes the 429 Error?

The most common cause of the 429 error is not having enough resources to handle so many concurrent requests.

For example, if this error is shown on a hosting server, it could mean that the package you’re using has a limit for the number of requests you can send.

And if the error comes up while making an API request, it means you’ve exceeded the number of requests you can make for a certain period of time.

Also, if a user tries to access a page on a website too often, the server of that website could trigger a rate-limiting feature implemented in it. So, this is a good security measure to put in place in order to prevent attacks from hackers.

For example, this is how you can implement rate limiting in an Express app using the express-rate-limit package:

// Import deps
const express = require("express");
const rateLimit = require("express-rate-limit");

const app = express();

// Port
const port = 4000;

const limiter = rateLimit({
  windowMs: 5 * 60 * 1000,
  max: 5, // Limits each IP to 5 per 15 minutes
  message:
    `<h1 style='display:flex; align-items:center; justify-content:center; height:100vh'>
     429 - Too many Requests <br> Try again later!
    </h1>`,
});

// Apply to all requests
app.use(limiter);

app.get("/", limiter, (req, res) => res.send("Hello World!"));

app.listen(port, () => console.log(`App listening on port ${port}!`));

And when the limit is surpassed for the number of seconds specified, this message gets shown to the user:

What you can do to Resolve the 429 Error

As an internet user, you should wait a bit before making another request. But if the error persists, you should contact the website administrator.

If you’re a web administrator, you should reduce the number of requests you make within the specified time (if any). If you are in control of the limit yourself, you should increase it for a particular period of time.

If the website you’re handling is a WordPress website, one of your plugins or themes might be causing the 429 error. You should disable your site plugins and themes one by one to see which one of them is the cause.

If the error is related to hosting, you should contact the customer care service of your hosting provider.

Conclusion

No website admin wants their server to get clunked up or crash. So, from a technical perspective, the 429 error is not an error. It’s the server’s way of telling you it doesn’t have enough resources to handle the high number of requests you’re making.

Thank you for reading.

On many occasions, this error is an issue with the website itself, so on your end, there’s nothing you can do to solve it.

But the error can also occur if your network adapters or network settings of your computer are badly configured.

The “502” in the error is an HTTP status code that indicates one server received an invalid response from another server.

Google shows the error this way:

Sometimes, a popular forum in my country shows it this way:

It looks like websites powered by Cloudflare show the error that way.

Some other websites show it in their own customized way.

What Exactly Does 502 Bad Gateway Mean?

The international engineering task force (IETF) defines the 502 Bad Gateway Error in a more extensive way:

The 502 (Bad Gateway) status code indicates that the server while acting as a gateway or proxy, received an invalid response from an inbound server it accessed while attempting to fulfill the request.

The “proxy server” is a system or router that acts as a gateway between your computer and the internet.

The inbound server, on the other hand, is the one conveying an incoming connection onto your computer. That is, a web server.

What Causes a Bad Gateway Error?

As earlier pointed out, 502 Bad Gateway is a server error just like other HTTP status code errors in the 500 range such as 501 (Not Implemented), 503 (Service Unavailable), 504 (Gateway Timeout), and 505 (HTTP Version not supported).

This particular server error could be an overloaded server, programming, and backend configuration error, or even a yet-to-be-propagated domain name.

But sometimes, the browser could throw this error due to past-due updates, ad-blockers, browser extensions, or computer DNS server problems.

Final Thoughts

I hope this article helps you understand what the 502 Bad Gateway error means.

If you’re a web administrator and your users are complaining of this error, you should try to fix it as soon as possible as it could have a negative effect on your website's SEO.

If you’re facing this error as a user, there’s a high chance it’s from the website you’re trying to visit. Some other times, it could be due to a badly configured router and settings.

You can try refreshing the web page, clearing your browser cache, and switching to another browser.

To see how you can solve the error as a user, I wrote a detailed article that can help you out.

Thank you for reading.

HTTP status codes allows us know if our request to the server was successful or not. Here are the status codes and what each type means:

• 100 - 199 (Informational).
• 200 - 299 (Successful).
• 300 - 399 (Redirection).
• 400 - 499 (Client error).
• 500 - 599 (Server error).

In this article, we'll be talking about the 504 error which falls under the server error category. We'll see some of the reasons why you might encounter this error and the possible ways of fixing it.

What Is the HTTP 504 Error?

From the status codes listed before this section, we can see that the 504 error is a server error. This means that it is not a problem from our end as the client. Our request was sent successfully to the server but something went wrong while we were awaiting a response.

You'll usually get a response saying "Gateway Timeout Error" or something similar if it is a 504 error.

This error occurs when our server doesn't receive a response fast enough from the server where our request was sent. As a result of the delay, our server times out and returns an error instead.

The reasons for this error can vary. The server where the request was sent to could be down for maintenance or overloaded, amongst other reasons.

How to Fix the HTTP 504 Error

In this section, we'll talk about some of the ways in which you can fix the 504 error.

The following solutions are for users visiting websites:

Refresh Your Browser

The first thing you should try when you encounter this error is to refresh your browser. Each browser usually has a shortcut for refreshing, but you can always use the refresh button.

Disconnect and Reconnect Your Network Devices

If refreshing your browser doesn't fix the problem then you should try disconnecting from and reconnecting to your network devices. This could be a modem, a router, a Wi-Fi hotspot, and so on.

Clear Browser Data and Cookies

Each browser has a way of clearing data and cookies but this is usually in the browser settings.

While this may fix the problem, you should know that in most cases, it doesn't – so be sure you are willing to get rid of the data and cookies before proceeding.

Find Out If Other Users Are Experiencing the Same Problem

If you are on any community platform or know other users who make use of the website then you should probably try and find out from them to see if it is a general problem.

If this is a general problem then you can sit back and relax. The website owners might be up to something on the backend.

Note that trying these fixes above may not work all the time. In situations like this, the best thing to do is to wait and try later because it is usually not a problem from your end as the client.

The following solutions are for you if you own a website:

Contact Your Hosting Provider

In cases where the website belongs to you and users cannot access it, you should try contacting your hosting provider to be sure everything is in check.

It could be as a result of your hosting plan requiring an upgrade because you may have reached the limits of your current plan.

Check for DNS Changes

When you change servers for your website, the DNS information changes will usually take some time before updating. So you can inform your users of changes like this before or after they happen.

DNS stands for Domain Name System. They change domain names to IP addresses which browsers can easily recognize before loading websites.

Conclusion

In this article, we talked about the HTTP 504 error. We talked about HTTP status codes and found out what category the 504 error belonged to.

We then talked about why this error might happen and some of the possible ways of fixing it.

Thank you for reading!

Before we get into REST, let's learn what an API is. I believe this will help you understand REST better.

What is an API?

Since we're talking about REST APIs, our definition of an API will not go beyond the scope of the web.

API stands for Application Programming Interface. An API establishes a connection between programs so they can transfer data.

A program that has an API implies that some parts of its data is exposed for the client to use. The client could be the frontend of the same program or an external program.

In order to get this data, a structured request has to be sent to the API. If the request meets the desired requirements, a response which contains the data gets sent back to where the request was made. This response usually comes in the form of JSON or XML data.

In some cases, you'll need some sort of authorization to gain access to external API data.

Every API has documentation that tells you what data is available and how to structure your request in order to get a valid response.

API Example

Was that confusing?

Let's use a real life scenario to give an example.

Imagine visiting a new restaurant. You're there to order food, and since you haven't been there before, you don't exactly know what type of food they serve.

The server then approaches you with a menu so you can pick what you'd like to eat. After making your choice, the server then goes to the kitchen and gets your food.

In this case, the server is the API who is connecting you to the kitchen. The API's documentation is the menu. The request is made when you pick what you'd like to eat, and the response is the food being served.

I hope that helps you understand what an API is and how it works.

What is REST?

REST stands for REpresentational State Transfer. It is a standard that guides the design and development of processes which enable us interact with data stored on a web servers.

The above definition may not look as complex or "professional" as the ones you come across on the internet, but the goal here is for you to understand the basic purpose of REST APIs.

An API that complies with some or all of the six guiding constraints of REST is considered to be RESTful.

We are able to communicate with servers using the HTTP protocol. With these protocols, we can Create, Read, Update and Delete data – otherwise known as CRUD operations.

But how can we perform these CRUD operations and communicate with data on the server?

We can do this by sending HTTP requests, and that is where REST comes in. REST simplifies the communication process by providing various HTTP methods/operations/verbs which we can use to send requests to the server.

How to communicate with a server using REST APIs

As we discussed in the last section, REST APIs make the communication process with the server easier for us by giving us various HTTP request methods. The most commonly used methods are:

• GET: The get method is used to Read data on the server.
• POST: The post method is used to Create data.
• PATCH/PUT: The patch method is used to Update data.
• DELETE: The delete method is used to Delete data.

These methods provided by REST allow us perform CRUD operations easily. That is:

Create => POST.
Read => GET.
Update => PATCH/PUT.
Delete => DELETE.

So if we are to make a request to a server, let's say to retrieve data, we are going to make a GET request to an endpoint/resource provided by the server. The endpoint is similar to a URL.

If the request made is a valid one, then the server will respond to us with the data we requested. It also sends a status code where 200 is a success and 400 is a client error.

Here is an example of a request made to the JSONPlaceholder API using JavaScript:

fetch('https://jsonplaceholder.typicode.com/todos/1')
  .then(response => response.json())
  .then(json => console.log(json))

When making a request using the fetch API, the default method is the GET method – so we are not forced to specify it. But we do need to specify when making a request using the other methods.

In the code example above, the endpoint is https://jsonplaceholder.typicode.com and the specific data we are requesting is one todo item. The data will be returned to us in JSON format.

If we were to make a POST request, then we would include the method type which would be POST and a request body which would contain the data we are creating to send to the server.

Deleting would require that we use the corresponding request method along with the id of the todo item we want to delete. Like this:

fetch('https://jsonplaceholder.typicode.com/posts/3', {
  method: 'DELETE',
});

Updating would require both the id and the request body that would be used to update the data. Here is an example:

fetch('https://jsonplaceholder.typicode.com/posts/5', {
  method: 'PATCH',
  body: JSON.stringify({
    title: 'new todo',
  }),
  headers: {
    'Content-type': 'application/json; charset=UTF-8',
  },
})
  .then((response) => response.json())
  .then((json) => console.log(json));

Conclusion

In this tutorial, you learned what REST is and how it helps us communicate with the server efficiently.

We defined an API and gave an example to help explain its meaning. We also got to know some of the methods provided by REST to create, read, update and delete data stored on the server.

Thank you for reading!