Coder Legion - Recent posts tagged http

Debug HTTP 422 API Validation Errors Safely

Wed, 14 Oct 2026 03:03:25 +0000

When an API returns an HTTP 422 response, client integrations often discard field-level details or dump entire response bodies into logs.

Quick solution:

async function readAndFormat422(response: Response): Promise<string> {
  const raw = await response.text();
  try {
    const body = JSON.parse(raw);
    const errors = body.errors;
    if (errors && typeof errors === "object") {
      return Object.entries(errors)
        .slice(0, 10)
        .map(([field, val]) => field + ": " + String(val))
        .join("; ");
    }
    return body.message || "Unprocessable content";
  } catch {
    return raw.slice(0, 200);
  }
}

HTTP 422 is one of those status codes that is specific enough to sound useful and vague enough to waste an hour. The server understood the request content type and syntax, but could not process the instructions in the payload.

What HTTP 422 actually tells you

RFC 9110 defines 422 Unprocessable Content as a case where the server understands the content type and the syntax is correct, but cannot process the contained instructions. MDN’s 422 reference summarizes the status as well. Because providers return inconsistent error-body schemas, your client must handle varied shapes safely without assuming a universal structure.

The anti-patterns of error handling

Catching non-2xx responses by keeping only the status code strips out all valuable context, turning detailed validation failures into generic messages. Conversely, logging the raw response text directly often leaks user input, tokens, or unexpected internal details into your observability stack.

Redacting and bounding output

Always bound character lengths and field counts to prevent memory bloat or log floods, and sanitize sensitive patterns like bearer tokens before persistence. For related architectural workflows, consult Designing a Reliable Serverless AI Publishing Workflow and Building a Reliable Batch Publishing Workflow.

Verification checklist

Read error bodies exactly once as text before parsing.
Enforce structural limits on extracted error fields.
Sanitize output strings for authorization tokens.
Confirm 422 responses do not trigger infinite retry loops.

HTTP Just Got a New Method After 16 Years—Meet QUERY.

Sun, 20 Sep 2026 09:21:23 +0000

The New HTTP QUERY Method: The First New HTTP Method in 16 Years

What if you could have the simplicity of GET with the flexibility of POST? That's exactly what the new HTTP QUERY method aims to deliver.

If you've built REST APIs, you've probably faced this situation before.

You need to fetch data from your server, so naturally, GET seems like the right choice. But then your filters become more complex. You need nested objects, multiple conditions, sorting, pagination, maybe even advanced search criteria. Suddenly, your URL starts looking like a puzzle.

GET /orders?status=paid&customer=Ravi&from=2026-01-01&to=2026-06-30&sort=-amount&page=2&include=products,shipping,payments

As the application grows, that URL only gets longer and harder to manage.

Most developers eventually switch to POST for search endpoints, even though they're only retrieving data.

For years, this has been one of the awkward compromises in REST API design.

That changes with the new QUERY HTTP method, standardized in RFC 10008 (June 2026).

Why Was QUERY Needed?

Let's understand the problem first.

Imagine you're building an e-commerce platform.

A user wants to search orders based on:

Customer name
Order status
Date range
Price range
Multiple product categories
Sort order
Pagination

With GET, everything has to fit inside the URL.

GET /orders?customer=Ravi&status=paid&category=laptop&category=gaming&page=3&sort=-price

This works...

...until it doesn't.

As the filters become more advanced, URLs become difficult to read, difficult to encode correctly, and can even exceed practical length limits imposed by browsers, servers, or proxies.

Another downside is that query parameters often appear in logs, browser history, and analytics systems, making them less suitable for sensitive search criteria.

Clearly, developers needed a better solution.

Why Not Just Use POST?

This is exactly what many APIs do today.

POST /orders/search
Content-Type: application/json

`{
"customer": "Ravi",
"status": "paid",
"categories": [

"Laptop",
"Gaming"

],
"price": {

"min": 500,
"max": 2000

},
"page": 3
}`

The request body solves many problems.

It's clean.

It's readable.

It supports complex JSON.

So what's wrong?

The issue isn't technical.

It's semantic.

POST traditionally represents an operation that may change server state.

Searching for data doesn't.

Using POST for read-only operations has always been a compromise because HTTP infrastructure can't safely assume the request is cacheable or automatically retryable.

Meet QUERY

QUERY combines the strengths of both GET and POST.

Instead of placing filters in the URL, you send them inside the request body.

QUERY /orders
Content-Type: application/json

`{
"customer": "Ravi",
"status": "paid",
"categories": [

"Laptop",
"Gaming"

],
"price": {

"min": 500,
"max": 2000

}
}`

Unlike POST, QUERY is explicitly defined as a safe and idempotent method.

That means everyone involved—the client, server, proxy, and cache—knows that executing the request will not modify server data.

This makes QUERY a much better fit for complex searches.

What Does "Idempotent" Actually Mean?

You'll often hear this word when talking about HTTP methods.

An operation is idempotent if performing it multiple times has the same effect as performing it once.

For example:

GET /users/42

Calling this request one time or ten times returns the same user.

Now compare that to:

POST /users

Calling it twice could create two different users.

That's why POST isn't considered idempotent.

QUERY behaves like GET in this regard.

If the network connection drops halfway through the response, a client can safely retry the QUERY request without worrying about accidentally changing server data.

Why This Matters

The QUERY method brings several advantages:

✅ Supports complex request bodies
✅ Safe for read-only operations
✅ Idempotent
✅ Easier for caching systems to understand
✅ Better HTTP semantics

Instead of inventing custom search endpoints like:

POST /users/search
POST /orders/filter
POST /products/query

Applications can eventually expose cleaner APIs using QUERY.

A Practical Example

Imagine you're building an analytics dashboard.

Today's API might look like this:

POST /analytics/report

Request body:

`{
"dateRange": {

"from": "2026-01-01",
"to": "2026-06-30"

},
"groupBy": "country",
"metrics": [

"sales",
"profit"

]
}`

The request doesn't create anything.

It simply retrieves data.

QUERY expresses that intent much more clearly.

QUERY /analytics/report

Same body.

Better semantics.

What About Spring Boot and Other Frameworks?

If you're a Java developer like me, you've probably written endpoints such as:

@PostMapping("/search")

even though they're only returning data.

At the time of writing, most frameworks—including Spring Boot, Express, FastAPI, ASP.NET Core, and many API gateways—don't yet provide first-class support for QUERY because the standard is still very new.

As ecosystem support grows over the next few years, it will be interesting to see how frameworks adopt it.

Should You Use QUERY Today?

Probably not in production.

Although the method has now been standardized, widespread support is still limited.

Many HTTP clients, frameworks, reverse proxies, API gateways, and developer tools have yet to implement it.

For now, the common approach remains:

Use GET for simple resource retrieval.
Use POST when you need complex search bodies and QUERY isn't available.
Keep an eye on framework support as the ecosystem evolves.

Final Thoughts

HTTP has remained remarkably stable over the years, and that's a good thing.

But there has always been a missing piece between GET and POST.

QUERY fills that gap by providing a standard way to perform complex, read-only requests without sacrificing HTTP semantics.

Will it replace GET?

No.

Will it replace POST?

Not entirely.

Instead, it gives developers a better tool for scenarios where neither GET nor POST feels quite right.

It may take a few years before QUERY becomes common in production APIs, but understanding it today will help you design better APIs tomorrow.

What do you think about the new QUERY method?

Would you use it once your favorite framework supports it? Let me know in the comments!

Thanks for reading! If you enjoyed this article, consider leaving a ❤️ and following me here on DEV Community for more content on Java, Spring Boot, backend engineering, and modern web technologies.

Building an HTTP Server From Scratch using TCP.

Tue, 15 Sep 2026 20:00:16 +0000

HTTP is something I interact with every single day, whether I am fetching data on the frontend or building backend APIs. But for a long time, if you had asked me how it actually worked under the hood, I wouldn't have had a good answer. I always treated HTTP like this intimidating, hyper-complex black box that would be miserable to understand, let alone rebuild from scratch. Once I actually dug into the internals, though, I realized the core mechanics are surprisingly straightforward.

I am using Go for this project, but the concepts are entirely language-agnostic. You can follow along in C, Rust, Python, Node, or whatever language you like; as long as it can open a network socket (sorry, HTML and CSS won't cut it here).

To understand HTTP, we first have to talk about TCP/IP, because HTTP is just a text-protocol riding on top of TCP/IP stack.

The Internet Protocol (IP) has one basic job: move raw data from Machine A to Machine B across the world. But it doesn't dump a massive file across the wire all at once. If you download a 10 GB file, IP chops that data into tiny pieces called packets, usually around 1,500 bytes each. It does this because network hardware has physical transmission limits, routers need to share bandwidth fairly among thousands of users, and resending one dropped 1.5 KB packet over flaky Wi-Fi is painless compared to re-downloading an entire 10 GB stream.

Every device on the internet gets an IP address so these packets know where to go. When you want to visit google.com, your computer doesn't magically know Google's physical server address right away. It first asks a DNS server to translate google.com into an actual IP address, like 142.250.190.46. Once your machine has that destination IP, it stamps its own IP address into the packet header so Google knows where to send the reply, and fires the packets into the wild.

The catch is that IP is completely "best-effort." It launches packets into the network and immediately stops caring. If a router gets overloaded and drops your packet, or if packets take different routes and arrive completely out of order, IP won't fix it.

That is why we need TCP (Transmission Control Protocol).

TCP sits right on top of IP to turn that chaotic packet delivery into a reliable stream. It tracks every byte with sequence numbers so out-of-order data gets assembled correctly. If a packet goes missing, TCP notices and asks the sender to retransmit it. It also introduces the concept of ports; so when data finally arrives at a computer's IP address, the operating system knows whether to hand those bytes to your web server on port 80 or your database on port 5432.

So now TCP has solved our biggest headache. We have a solid, reliable pipe open between our client and our server. You throw bytes into one end, and they pop out the other end in the exact right order without getting lost.

Problem solved, right? Not even close.

Because while TCP is great at moving bytes from one place to another reliably, it is completely blind to what those bytes actually mean. It treats everything as one never-ending, continuous river of data (a raw byte stream). If your browser sends a request to load a profile picture, and immediately sends another request for a stylesheet, TCP just mashes all those bytes together in a single stream.

Your server is now sitting there staring at a raw chunk of bytes, completely clueless:

Where does the first request end and the second one begin?
Is the client trying to download a file, submit a form, or delete a record?
Is this data plain text, an image, or JSON?
If something goes wrong on the server, how do we tell the client?

If we didn't have a standard rulebook, every single developer would invent their own chaotic format. You'd write your own custom protocol where maybe you put an exclamation mark at the end of a message, while someone else uses a random binary flag. Your backend wouldn't be able to talk to any standard browser because neither speaks the same language.

This is where HTTP (Hypertext Transfer Protocol) steps in.

HTTP is nothing more than an agreed-upon rulebook. If TCP is a telephone line connecting two people, HTTP is the grammar they agree to speak so they understand each other.

At its core, HTTP turns that blind stream of TCP bytes into predictable, structured messages. In HTTP/1.1, it does this entirely using plain text:

First, it forces the client to state its intent right on the very first line: like GET /index.html HTTP/1.1. Now the server instantly knows the action (GET), the target (/index.html), and the protocol version.

Next, it uses standard key-value headers separated by clean line breaks; specifically \r\n (CRLF: Carriage Return + Line Feed). Why two characters instead of just \n? Because early internet protocols inherited typewriter conventions from telegraph and terminal days, and now we are stuck with it forever.

Then, it solves the boundary problem with an empty line (\r\n\r\n), which screams to the parser: "Hey, the headers are done! Whatever comes next is the actual body payload."

Finally, the server replies with a standardized response that includes a status code like 200 OK if everything went well, or 404 Not Found if you asked for something that doesn't exist.

That's all HTTP really is. It's not magic, and it's not an intimidating engine. It's just a structured text format running over a raw TCP socket. Once you realize it's just plain text over a byte stream, building one yourself becomes a whole lot less scary.

What Does Raw HTTP Actually Look Like?

Before we write the code to parse requests and generate responses, let's look at the exact text format traveling across the wire.

1. The HTTP Request Format

When a client wants something from our server, it sends a plain-text payload formatted like this:

POST /users HTTP/1.1
Host: localhost:8080
User-Agent: curl/8.0.0
Accept: */*
Content-Type: application/json
Content-Length: 26

{"name": "Dev", "age": 22}

Line 1 (Request Line): Action (POST), path (/users), and version (HTTP/1.1), terminated by \r\n.
Lines 2–6 (Headers): Key-value metadata lines, each terminated by \r\n.
Line 7 (Empty Line): A single blank \r\n with no characters. This tells our server: "The headers are done."
Line 8 (Body Payload): Exactly 26 raw bytes of data matching the Content-Length header.

2. The HTTP Response Format

Once our server finishes processing, it writes back an answer formatted like this:

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

{"message": "user list endpoint"}

Line 1 (Status Line): Version (HTTP/1.1), status number (200), and status message (OK), followed by \r\n.
Lines 2–3 (Headers): Key-value details about what we are sending back, terminated by \r\n.
Line 4 (Empty Line): A single blank \r\n to mark the end of response headers.
Line 5 (Body Payload): Exactly 35 raw bytes of data sent down the wire.

Now that we know the format for both directions, let's build the server to handle it.

Building an HTTP Server from Raw TCP

I like to break the implementation down into four distinct steps:

Initialize a TCP socket and bind it to a local port.
Accept incoming client connections in a loop.
Read raw bytes from the socket and parse the HTTP request.
Construct an HTTP response and write those bytes back over the wire.

1. Setting Up the TCP Listener

In any programming language, listening for network traffic comes down to a few basic steps. You ask the operating system to reserve a port (like 8080), and then you wait for someone to connect.

package main

import (
"fmt"
"log"
"net"
)

func main() {
// Ask the OS to open port 8080 and listen for incoming traffic
listener, err := net.Listen("tcp", ":8080")
if err != nil {
log.Fatal("[SERVER] Failed to bind to port: ", err)
}
// Make sure we release the port when the server stops
defer listener.Close()

fmt.Println("[SERVER] Listening on port :8080...")

// Keep the server running in an infinite loop to accept other connections
for {
// Our program pauses right here until a client connects
conn, err := listener.Accept()
if err != nil {
fmt.Printf("[SERVER] Failed to accept connection: %v\n", err)
continue
}

// Pass the connection to a background worker so the loop can keep spinning
go handleConnection(conn)
}
}

What is happening here?

Binding: The operating system locks port 8080 for us. From now on, any data sent to this port comes straight to our app.
Accepting: Our program pauses and waits. When a client finally connects, the operating system wakes us up and hands us a connection object (conn).
Concurrency: If we try to process this connection right here in the main loop, our server will freeze for everyone else. So, we hand the connection off to run in the background. Go uses goroutines, Python might use threads, and Node uses its event loop. The idea is exactly the same: move the work out of the way so we can instantly wait for the next person.

2. The Request Lifecycle (`handleConnection`)

Before we dive into the details of parsing, let's look at the whole journey of a single connection.

Our handleConnection function does four things in order: it wraps the raw socket to read from it easily, parses the incoming text into a request we can understand, checks the URL path to see what the user wants, and sends back a text response.

func handleConnection(conn net.Conn) {
// Always close the connection when we are completely done
defer conn.Close()
clientAddr := conn.RemoteAddr().String()

// Wrap the raw connection in our custom stream reader
reader := stream.NewReader(conn)

// Try to make sense of the incoming bytes
req, err := request.Parse(reader)
if err != nil {
// If they sent garbage data, reply with a 400 Bad Request
res := response.New()
res.SetStatus(400)
res.SetBody([]byte("400 Bad Request"), "text/plain")
_ = res.Send(conn)
return
}

// Prepare a blank response to fill out
res := response.New()

// Basic routing: look at the path and decide what to send back
switch req.Path {
case "/":
res.SetStatus(200)
res.SetBody([]byte("Welcome to my scratch HTTP Server!"), "text/plain")
case "/users":
res.SetStatus(200)
res.SetBody([]byte(`{"message": "user list endpoint"}`), "application/json")
default:
// If we don't recognize the path, send a 404
res.SetStatus(404)
res.SetBody([]byte("404 Page Not Found"), "text/plain")
}

// Push the final formatted text back through the socket
_ = res.Send(conn)
}

We break this workload into three clear pieces:

stream: Safely reads a continuous flow of bytes from the connection.
request: Turns those raw bytes into structured HTTP data (methods, paths, and headers).
response: Formats our answer into valid HTTP text and pushes it back to the user.

3. Reading the Raw Byte-Stream (`pkg/stream`)

The network doesn't understand neat lines of text; it just gives us raw chunks of bytes. If we try to read one byte at a time directly from the network just to find a newline character, it is incredibly slow.

The universal fix for this is buffering. Instead of reading byte by byte, we pull a large chunk of data (like 4KB) into our application's memory all at once. Once it is safely in our memory, we can quickly scan through it to find our lines.

package stream

import (
"bufio"
"io"
"strings"
)

type Reader struct {
buffered *bufio.Reader
}

func NewReader(r io.Reader) *Reader {
return &Reader{
// Pull data in large chunks to save time and system resources
buffered: bufio.NewReader(r),
}
}

func (r *Reader) ReadLine() (string, error) {
// Read bytes until we hit a newline character
lineBytes, err := r.buffered.ReadBytes('\n')
// Clean off the trailing \r\n before handing the string back
return strings.TrimRight(string(lineBytes), "\r\n"), err
}

func (r *Reader) ReadExact(count int) ([]byte, error) {
// Create an empty chunk of memory of exactly the size we need
buf := make([]byte, count)
// Block and fill the memory completely before moving on
_, err := io.ReadFull(r.buffered, buf)
return buf, err
}

We need two different ways to read:

Line-by-line: HTTP metadata (like headers) is separated by line breaks. We read line-by-line until we hit the empty line that tells us the headers are done.
Exact byte counts: The actual body of a request (like an uploaded image) is just raw data. It might have random line breaks in it. So, once the headers are done, we stop reading lines and instead read an exact number of bytes based on the Content-Length header.

4. Parsing the Request (`pkg/request`)

Now we write the parser to read that incoming text stream into a structured Go struct:

package request

import (
"fmt"
"strconv"
"strings"
"github.com/devxdh/http-from-scratch/pkg/stream"
)

type Request struct {
Method  string
Path    string
Version string
Headers map[string]string
Body    []byte
}

func Parse(reader *stream.Reader) (*Request, error) {
req := &Request{Headers: make(map[string]string)}

// 1. Grab the very first line (e.g., "GET / HTTP/1.1")
line, err := reader.ReadLine()
if err != nil { return nil, err }

// Break the line into chunks using spaces
fLineArr := strings.Split(line, " ")
if len(fLineArr) < 3 { return nil, fmt.Errorf("Malformed request line") }

// Assign Method, Path, and Version respectively
req.Method, req.Path, req.Version = fLineArr[0], fLineArr[1], fLineArr[2]

// 2. Start reading the headers line by line
for {
line, err := reader.ReadLine()
if err != nil { return nil, err }

// An empty line means the headers section is completely done
if line == "" { break } 

// Split at the first colon we see (e.g., "Host: localhost")
headerLine := strings.SplitN(line, ":", 2)
if len(headerLine) < 2 { continue }

// Lowercase the key so we can easily search for it later
key := strings.ToLower(strings.TrimSpace(headerLine[0]))
req.Headers[key] = strings.TrimSpace(headerLine[1])
}

// 3. If there is a body, figure out how long it is
if val, ok := req.Headers["content-length"]; ok {
contentLength, err := strconv.Atoi(val)
if err != nil {
return nil, fmt.Errorf("Invalid content-length: %s", val)
}
// Read that exact number of bytes directly into our request body
req.Body, err = reader.ReadExact(contentLength)
if err != nil {
return nil, fmt.Errorf("Failed to read body: %v", err)
}
}

return req, nil
}

I keep two rules in mind when parsing:

Case-Insensitivity: HTTP header names don't care about uppercase or lowercase. We convert them all to lowercase right away so we don't run into bugs later when searching for "Content-Length".
Splitting Headers: Some headers have colons in their values (like Host: localhost:8080). We only split on the very first colon we see, so we don't accidentally cut the data in half.

5. Writing the HTTP Response (`pkg/response`)

Sending an answer is doing the exact reverse of parsing. We build a block of text containing our Status Line, our Headers, and a mandatory empty line. Then we push that text, along with any body data, back through the connection.

package response

import (
"fmt"
"io"
"strings"
)

var StatusRegister = map[int]string{
200: "OK",
  400: "Bad Request",
  404: "Not Found",
}

type Response struct {
StatusCode int
StatusText string
Headers    map[string]string
Body       []byte
}

func New() *Response {
return &Response{
StatusCode: 200,
StatusText: StatusRegister[200],
Headers:    make(map[string]string),
}
}

func (res *Response) SetHeader(key, value string) {
res.Headers[key] = value
}

func (res *Response) SetBody(body []byte, contentType string) {
res.Body = body
// Only set a content type if we actually provided one
if contentType != "" {
res.SetHeader("Content-Type", contentType)
}
}

func (res *Response) SetStatus(code int) {
text, ok := StatusRegister[code]
if !ok {
text = "Unknown"
}
res.StatusCode = code
res.StatusText = text
}

func (res *Response) Send(w io.Writer) error {
// We use a builder to efficiently glue all our text together
var builder strings.Builder

// 1. Start with the Status Line
fmt.Fprintf(&builder, "HTTP/1.1 %d %s\r\n", res.StatusCode, res.StatusText)

// Automatically count bytes so the client knows when to stop reading
res.SetHeader("Content-Length", fmt.Sprintf("%d", len(res.Body)))

// 2. Add all the headers, making sure to use \r\n
for key, val := range res.Headers {
fmt.Fprintf(&builder, "%s: %s\r\n", key, val)
}

// 3. Add the blank line that tells the client headers are done
fmt.Fprint(&builder, "\r\n")

// Push the constructed text block to the socket
_, err := w.Write([]byte(builder.String()))
if err != nil { return err }

// 4. Finally, push the raw body payload (if we have one)
if len(res.Body) > 0 {
_, err = w.Write(res.Body)
}
return err
}

Why I build it this way:

Automatic Content-Length: We count the bytes of our body payload right before sending and set the Content-Length header ourselves. If we don't tell the client exactly how much data to expect, it might hang forever waiting for more.
Send in one go: We build the entire text block of headers in memory first, and then send it all at once. This keeps things fast and simple.

6. Testing the Server with `curl -v`

Now that every component is in place, we can start our server and test it using curl -v (verbose mode).

You can automate this using a simple Makefile:

.PHONY: start test-get test-users test-post test-404

start:
go run ./main.go

test-get:
curl -v http://localhost:8080/

test-users:
curl -v http://localhost:8080/users

test-post:
curl -v -X POST http://localhost:8080/users \
-H "Content-Type: text/plain" \
-d "This is super horsey TCP/IP payload."

test-404:
curl -v http://localhost:8080/non-existent-path

Run make start in one terminal, and make test-users in another. Here is what the raw TCP exchange looks like:

* Connected to localhost (127.0.0.1) port 8080
> GET /users HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/8.0.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: application/json
< Content-Length: 35
< 
{"message": "user list endpoint"}

Lines starting with > are the raw plain-text HTTP request bytes sent by curl over the TCP socket.
The empty line right after Accept: */* is the \r\n\r\n boundary our parser scanned for.
Lines starting with < are the raw response bytes constructed by our response.Send function and pushed down the socket.

Because HTTP is fundamentally plain text over TCP, you could even talk to this server by sending raw text through Netcat (nc localhost 8080).

Source Code: http-from-tcp

Building an HTTP server from scratch demystified a lot of networking magic. Hope you got some value form this blog :).

Making HTTP Better on ESP32

Sat, 05 Sep 2026 09:23:34 +0000

HTTP on ESP32 Isn't Hard. The Unnecessary Work Around It Is.

Making an HTTP request from an ESP32 is relatively straightforward.

Connect to Wi-Fi, create an HTTP client, send a request, receive a response.

The real challenge usually appears later.

As an embedded application grows, HTTP communication starts accumulating responsibilities:

Authentication tokens
Custom headers
Query parameters and dynamic paths
JSON request bodies
JSON response parsing
Temporary buffers
Memory allocations
Repeated connections
Error handling and status validation

None of these things are particularly difficult on their own.

The problem is the amount of unnecessary work surrounding a simple HTTP request.

On a server or desktop application, that overhead might not matter much. On an ESP32 running continuously alongside sensors, Wi-Fi, display drivers, Bluetooth, and other tasks, memory usage and repeated allocations can become much more important.

This article explores a question I started asking while building ESP32 applications:

How much work does an ESP32 actually need to do to make an HTTP request?

A Simple Request Can Turn Into a Long Workflow

Consider a common situation.

An API returns the following JSON:

{
  "temperature": 24.8,
  "humidity": 68,
  "device": {
    "id": "esp32-office",
    "location": "office"
  },
  "metadata": {
    "version": "1.4",
    "updatedAt": 1725500000
  }
}

But your ESP32 only needs this:

temperature
device.id

A traditional workflow might look like this:

HTTP Request
     ↓
Receive the complete response
     ↓
Store the response in memory
     ↓
Create a JSON document
     ↓
Parse the entire JSON
     ↓
Navigate through the structure
     ↓
Extract two values
     ↓
Discard temporary data

This approach is completely valid.

In fact, a full JSON parser is often the right solution when your application genuinely needs to work with an entire JSON document dynamically.

But there is an important question:

If the application already knows exactly which values it needs, do we need to allocate and process everything else?

That question became the starting point for a different approach.

The Real Cost Isn't HTTP

HTTP itself is not necessarily the problem.

The surrounding workflow often is.

A request can involve:

Create Client
     ↓
Configure Headers
     ↓
Build Authentication
     ↓
Format URL & Query Parameters
     ↓
Build JSON Request Body
     ↓
Open Connection
     ↓
Send Request
     ↓
Receive Response
     ↓
Store Response
     ↓
Allocate JSON Document
     ↓
Parse JSON
     ↓
Extract Values
     ↓
Destroy Temporary Objects

Repeat that process continuously, and things become more interesting.

For an ESP32 application that runs for hours, days, or even months, developers often start thinking about questions that are less important in traditional applications:

How often am I allocating memory on the heap?
Am I storing data I don't actually need?
Can I reuse this connection across requests?
Can authentication configuration persist without repeated boilerplate?
Can I avoid repeatedly rebuilding headers and URLs?
Can I extract only the fields I care about directly into variables?
Will a missing JSON key crash my device or leave it in an unstable state?

The goal isn't to eliminate every allocation at all costs.

The goal is to avoid allocations and processing that don't provide value to the application.

Memory Predictability Matters on Embedded Devices

The ESP32 is a capable microcontroller, but it still operates under resource constraints.

An embedded application might be handling several things simultaneously:

ESP32 Application
│
├── Wi-Fi
├── Sensors
├── Display
├── Bluetooth
├── FreeRTOS Tasks
├── HTTP Communication
└── Application Logic

Every component competes for memory.

This is why memory predictability can be just as important as raw performance.

Repeated dynamic allocations are not automatically bad. However, when an application performs frequent network operations over long periods, reducing unnecessary temporary allocations can help create a more predictable memory profile.

This becomes particularly relevant when dealing with HTTP responses.

Do You Really Need the Entire JSON Response?

Let's return to the earlier example.

Suppose the ESP32 only needs:

temperature
device.id

Instead of building an entire JSON structure in memory, another approach is to bind those fields directly to variables.

For example:

float temperature;
char deviceId[32];

client.get("/sensor")
      .getBody("temperature", &temperature)
      .getBody("device.id", deviceId, sizeof(deviceId));

The application tells the HTTP client:

When you find temperature, write it here.

And:

When you find device.id, write it here.

The application doesn't need to manually navigate through a JSON document afterward.

The values go directly to their final destination.

This concept is called response binding, and it became the central idea behind my library, ESP32-HTTP-Client.

Instead of following this workflow:

Response
   ↓
String
   ↓
JSON Document
   ↓
Extract Values

The workflow becomes:

Response Stream
   ↓
Find Required Fields
   ↓
Write Directly Into Variables

The complete response body does not need to be stored before processing.

The library processes the response as a stream and binds matched fields directly to the variables provided by the application.

Nested Paths, Arrays, and Missing Keys

Response binding isn't limited to shallow properties. It supports deep dot notation and numeric array indexing:

char city[32];
int secondReading;

client.get("/data")
      .getBody("sensors.0.readings.1", &secondReading)
      .getBody("device.location.city", city, sizeof(city));

And critically for embedded reliability: if a key is missing or the schema changes, the target variable is simply left untouched. The library does not crash, throw exceptions, or leave memory in an inconsistent state.

Reducing Work Means More Than Reducing Memory

Memory was one motivation behind this approach.

But reducing unnecessary work can also improve code simplicity.

Consider the amount of code developers often write around a simple request using the standard ESP32 libraries (HTTPClient + ArduinoJson):

// The traditional approach: ~15-20 lines of procedural boilerplate
HTTPClient http;
http.begin("https://api.example.com/report");
http.addHeader("Authorization", "Bearer my-jwt-token");
http.addHeader("X-Device-ID", "ESP32-001");

int code = http.GET();
if (code == HTTP_CODE_OK) {
    // 1. Read complete payload into RAM (heap allocation #1)
    String payload = http.getString();

    // 2. Allocate JSON document (heap allocation #2)
    DynamicJsonDocument doc(2048);
    DeserializationError err = deserializeJson(doc, payload);

    if (!err) {
        // 3. Navigate structure and copy values manually
        int userId = doc["userId"];
        float temperature = doc["sensor"]["temp"];
        char city[32];
        strncpy(city, doc["address"]["city"] | "", sizeof(city));
    }
}
http.end();

Notice everything that happens here:

Authentication and headers are rebuilt for every single request.
Intermediate buffers (payload String and doc JSON tree) are allocated on the heap to store data the application will never use.
Manual parsing and navigation are written out imperatively.
Cleanup and disposal repeat on every iteration.

A good abstraction should reduce repetition without hiding important control from the developer.

With ESP32-HTTP-Client, those responsibilities are divided where they actually belong:

Authentication and headers belong to the client configuration and are declared once (client.bearer(...), client.setHeader(...)), persisting automatically across requests.
Buffers and deserialization are bypassed entirely—the response stream binds matched values straight into your destination variables.

So when the goal is simply to retrieve a few values from an API, the application code expresses only its actual intent:

int userId;
float temperature;
char city[32];

// Client already has auth & headers; request simply fetches and binds:
client.get("/report")
      .getBody("userId", &userId)
      .getBody("sensor.temp", &temperature)
      .getBody("address.city", city, sizeof(city));

The code describes the application's actual intent:

Make a request and give me these values.

And if a specific request needs query parameters, a custom timeout, or needs to capture a response header, they fold into the exact same fluent chain without extra boilerplate:

String token;

client.get("/report")
      .query("period", "latest")
      .timeout(5000)
      .getHeader("Authorization", &token)
      .getBody("userId", &userId)
      .getBody("sensor.temp", &temperature)
      .getBody("address.city", city, sizeof(city));

That is the philosophy behind the fluent API used by ESP32-HTTP-Client.

Fluent Payloads and Full REST Support

This fluent design isn't limited to GET requests. REST communication is two-way.

Building JSON request bodies manually with snprintf or String concatenations frequently introduces subtle formatting bugs and heap churn. With ESP32-HTTP-Client, sending structured data is just as straightforward:

int newId;

// POST request with fluent JSON body construction
client.post("/devices")
      .body("name", "ESP32-Office")
      .body("interval", 30)
      .body("active", true)
      .getBody("id", &newId);

The client provides first-class support for all standard REST methods: get(), post(), put() (with update() as an alias), patch(), and del().

Path and Query Parameters Without String Concatenation

Dynamic URLs in Arduino sketches are typically built with repetitive string operations:

// Fragile and causes heap fragmentation:
String url = "/devices/" + String(deviceId) + "/readings?limit=" + String(limit);

ESP32-HTTP-Client solves this at the builder level with .path() and .query():

client.get("/devices/{id}/readings")
      .path("id", deviceId)
      .query("limit", 20)
      .query("filter", "active")
      .getBody("summary.count", &count);

Placeholders are replaced and query parameters are appended smoothly, keeping the code readable and avoiding intermediate String objects on the heap.

Beyond Primitives: Struct <-> JSON Mapping

Binding individual primitive variables works well for small endpoints. But in production firmware, you often work with structured data models.

Traditionally, handling a data model on an ESP32 involves:

Allocating a DynamicJsonDocument.
Parsing the incoming JSON.
Manually copying each field into a C++ struct.
Freeing the document.
Repeating the reverse process whenever you need to serialize the struct to send it back.

ESP32-HTTP-Client addresses this with zero-allocation bidirectional struct mapping via the REST_JSON_MAP macro:

struct DeviceConfig {
    float telemetryInterval = 60.0;
    bool enabled = true;
    char mode[16] = "normal";

    REST_JSON_MAP(
        REST_FIELD(telemetryInterval),
        REST_FIELD(enabled),
        REST_FIELD(mode)
    )
};

Once declared, the struct can be populated directly from an API response:

DeviceConfig config;

// The network stream binds directly into the struct fields
client.get("/device/config").getBody(&config);

And sending a struct to an API is just as clean:

client.post("/device/config").body(config);

No intermediate JSON documents to size or manage. Serialization and deserialization happen directly between your native C++ structures and the network stream.

Authentication Shouldn't Become Repeated Boilerplate

Performance and memory are only part of the problem.

Authentication is another common source of repeated HTTP boilerplate.

Many IoT APIs require authentication using:

Bearer tokens
JWT tokens
HTTP Basic Authentication
API Keys
Custom headers

Without a reusable abstraction, authentication logic can easily start appearing before every request.

For example:

Request A
 ├── Add Authorization Header
 └── Send Request

Request B
 ├── Add Authorization Header
 └── Send Request

Request C
 ├── Add Authorization Header
 └── Send Request

But authentication usually belongs to the client configuration, not to every individual request.

A reusable client can configure authentication once:

client.bearer("your-jwt-token");

Then continue making requests:

client.get("/profile");

client.get("/devices");

client.get("/telemetry");

The authentication header persists across subsequent requests made by that client instance.

The same idea applies to Basic Authentication:

client.basic("username", "password");

And API keys:

client.apiKey("X-API-Key", "your-api-key");

The client also supports persistent custom headers:

client.setHeader("X-Device-ID", "ESP32-001");

These configurations remain associated with the client and are applied to subsequent requests.

Extracting Response Headers

What about headers returned by the server? Often, authentication tokens, rate limits, or server timestamps are sent in HTTP response headers rather than the JSON body.

Instead of writing custom header collection routines, you can extract response headers inside the same fluent chain:

String refreshedToken;
int rateLimit;

client.get("/telemetry")
      .getHeader("Authorization", &refreshedToken)
      .getHeader("X-RateLimit-Remaining", &rateLimit);

Header lookups are case-insensitive and can be captured into standard C types or Arduino Strings.

This may seem like a small improvement.

But in embedded applications, reducing repeated code also reduces the chances of inconsistent configuration between requests.

Reuse the Client, Not Just the Code

Another overlooked source of unnecessary work is connection management.

Imagine an application that does this repeatedly:

Create HTTP Client
      ↓
Connect
      ↓
Make Request
      ↓
Close Connection
      ↓
Destroy Client

Then starts again a few seconds later.

For applications making frequent requests to the same server, connection reuse can significantly reduce overhead.

ESP32-HTTP-Client enables HTTP Keep-Alive and reuses the underlying connection when possible, allowing subsequent requests to avoid unnecessarily rebuilding the connection.

The intended usage looks more like this:

ESP32HTTPClient client("https://api.example.com");

void loop() {
    float temperature;

    client.get("/sensor")
          .getBody("temperature", &temperature);

    delay(5000);
}

The client instance is reused.

That doesn't mean every application should keep a connection alive forever.

There are trade-offs.

An active HTTPS connection can retain TLS buffers in memory. According to the library's documented measurements, calling client.end() after a burst of requests can release resources when the device will remain idle for a long period.

So the better question isn't:

Should I always keep the connection alive?

It is:

Does connection reuse make sense for how frequently my device communicates?

That distinction matters.

Measuring the Difference

Performance claims without context are not particularly useful.

So I tested the approach using 100 consecutive HTTP GET requests with JSON responses on a real ESP32 device.

The benchmark compared:

Standard Approach
HTTPClient + ArduinoJson

vs.

ESP32-HTTP-Client
Streaming + Direct Response Binding

The Wi-Fi connection was already established before the benchmark started, and both approaches used their default configurations.

The documented benchmark results were:

Metric	HTTPClient + ArduinoJson	ESP32-HTTP-Client
Heap allocation per request	~58.2 KB	~15 bytes
Average RAM footprint	34.2%	24.3%
Minimum free heap	114.3 KB	128.6 KB
Average execution time	~750 ms	~59 ms

The difference comes from several architectural choices, including connection reuse and streaming JSON processing rather than storing the complete response and parsing it afterward.

However, these numbers should be interpreted correctly.

They represent this specific benchmark configuration.

They do not mean every HTTP request on every ESP32 application will be twelve times faster.

Network conditions, server behavior, payload size, TLS configuration, connection reuse, and application logic can all affect the result.

Benchmarking should always be reproducible and specific to the problem being solved.

The full benchmark setup and source information are documented with the project.

A More Practical Example

Let's consider a realistic IoT scenario.

An ESP32 communicates with a remote API.

It needs to:

Authenticate using a Bearer token.
Identify the device using a custom header.
Send telemetry periodically.
Receive configuration from the server.
Extract only the configuration values it needs.

The workflow looks like this:

               ESP32     
                 │
      Read Sensor Data (Temp & Humidity)
                 │
                 ▼
       Send Telemetry (POST /telemetry)
                 │
                 ▼
          Authenticated API
                 │
                 ▼
   Receive Configuration (GET /device/config)
                 │
                 ▼
     Extract Required Fields Directly

The client configuration happens once during initialization:

#include <WiFi.h>
#include "ESP32HTTPClient.h"

ESP32HTTPClient client("https://api.example.com");

void setup() {
    Serial.begin(115200);
    // Connect to Wi-Fi...

    // Configure persistent auth and headers once:
    client.bearer("your-jwt-token");
    client.setHeader("X-Device-ID", "ESP32-001");
}

Then, in the periodic loop, the application performs both the telemetry upload and configuration check without intermediate boilerplate:

void loop() {
    // 1. Read sensor data
    float currentTemp = 24.8;
    float currentHumidity = 65.0;

    // 2. Send telemetry via POST with a fluent JSON payload
    client.post("/telemetry")
          .body("temperature", currentTemp)
          .body("humidity", currentHumidity);

    if (client.isSuccess()) {
        Serial.println("Telemetry sent successfully.");
    }

    // 3. Retrieve server configuration via GET with direct response binding
    float interval = 30.0;
    bool enabled = true;

    client.get("/device/config")
          .getBody("telemetryInterval", &interval)
          .getBody("enabled", &enabled);

    if (client.isSuccess()) {
        Serial.printf("Config updated: interval=%.1fs, enabled=%d\n", interval, enabled);
    } else {
        Serial.printf("Request error [%d]: %s\n", 
                      client.getStatusCode(), 
                      client.getErrorMessage().c_str());
    }

    delay(interval * 1000);
}

The application does not need to manually:

Format a JSON string with snprintf or String additions.
Retrieve a complete JSON response string.
Allocate a JSON document on the heap.
Deserialize the document.
Navigate through the JSON structure.

Instead, it declares what it sends and what it expects.

That is a much closer representation of what the application actually needs.

But Should You Always Avoid a Full JSON Parser?

No.

This is important.

A full JSON library remains extremely useful.

There are situations where you genuinely need:

Dynamic JSON structures
Unknown fields
Complex transformations
Entire arrays
Full objects
Runtime exploration of a JSON document

In those situations, storing and manipulating the entire document may be the correct solution.

The goal is not:

Never use ArduinoJson.

The goal is:

Don't process more data than your application needs.

If your application requires only three predictable values from a large API response, direct response binding can be a simpler and more memory-conscious alternative.

If your application needs to inspect and manipulate an entire dynamic JSON document, a full JSON parser is probably the better tool.

Choosing the right abstraction depends on the problem.

When Does This Approach Actually Matter?

If your ESP32 sends one small request every few hours, HTTP optimization may not be your biggest concern.

But the approach becomes more interesting when your application:

Runs continuously.
Makes frequent requests.
Communicates with the same server repeatedly.
Has limited memory available.
Uses multiple peripherals (display, BLE, Wi-Fi, sensors).
Processes JSON responses.
Needs predictable memory usage without heap fragmentation.
Uses authentication across multiple API endpoints.

For these scenarios, reducing unnecessary allocations and repeated configuration can make the networking layer simpler and potentially more efficient.

The Idea Behind ESP32-HTTP-Client

I built ESP32-HTTP-Client around a simple question:

Can HTTP communication on an ESP32 be expressed closer to what the application actually needs?

Instead of:

Get everything
     ↓
Store everything
     ↓
Parse everything
     ↓
Use a small part

The approach becomes:

Request what you need
     ↓
Extract what you need
     ↓
Store it where you need it

The library combines several ideas:

Direct JSON response binding: Maps response values straight into primitive variables or native C++ structs (REST_JSON_MAP).
Streaming response processing: Parses data on the fly directly from the network stream with zero full-payload buffering.
Full REST suite with fluent payloads: Clean GET, POST, PUT, PATCH, and DELETE without manual string formatting.
Safe URL builders: Dynamic path parameters (.path()) and query strings (.query()) without dynamic String concatenation.
Response header extraction: Binds headers directly via .getHeader() in the same call.
Persistent authentication: Reusable Bearer tokens, Basic Auth, API keys, and custom headers.
HTTP Keep-Alive and connection reuse: Drastically reduces handshake latency across sequential requests.
Built-in reliability: Missing response fields never crash the device, and status checking (isSuccess(), callbacks) is baked in.

The objective was never simply to create another HTTP wrapper.

It was to question how much unnecessary work an ESP32 performs between:

"I need this data"

and:

"Here is the value."

Final Thoughts

Making HTTP requests on an ESP32 isn't difficult.

The challenge is everything that tends to accumulate around those requests as an application grows.

Authentication.

Headers.

Temporary buffers.

JSON parsing.

Repeated connections.

Repeated boilerplate.

For many projects, the traditional approach is perfectly fine.

But embedded development often benefits from asking a different question:

What work is actually necessary?

If the ESP32 already knows which values it needs from an API, processing and storing an entire response may not always be necessary.

If authentication remains the same across multiple requests, rebuilding the headers every time may not be necessary.

If the device communicates repeatedly with the same server, reconnecting from scratch may not always be necessary.

Small decisions like these can change how an embedded application behaves over time.

That is the idea behind ESP32-HTTP-Client:

HTTP isn't necessarily the expensive part. Sometimes, it's all the unnecessary work around it.

Explore the Project

ESP32-HTTP-Client is an open-source Arduino library designed for ESP32 applications that need a lightweight and fluent approach to REST communication.

You can explore the documentation, examples, benchmarks, and source code here:

ESP32-HTTP-Client Documentation

The HTTP QUERY method (RFC 10008) is here — and caching it correctly is harder than it looks

Wed, 19 Aug 2026 09:51:44 +0000

TL;DR

HTTP got a new method: QUERY (RFC 10008, June 2026). It's a safe, idempotent, cacheable request that carries a body — "GET with a body."
It fixes a decade-old pain: complex reads (search/filter/graph queries) that don't fit in a URL, without abusing POST.
The subtle part is caching: the RFC requires the request body to be part of the cache key. Get it wrong and one client gets another client's response.
http-queryable is a small library that does this correctly for Express, Fastify, raw http, and the browser.

What is the QUERY method?

For decades HTTP forced a bad choice for "reads with a big input":

GET — safe, idempotent, cacheable, but no body. Cram everything into the URL and hit length limits.
POST — has a body, but it's unsafe and non-idempotent. Caches and proxies won't treat it as a read, and you can't safely retry.

QUERY is the missing middle: a body like POST, but the semantics of GET — safe, idempotent, and cacheable.

QUERY /search HTTP/1.1
Content-Type: application/json

{ "q": "cats", "filters": { "color": "black" } }

The catch nobody talks about: caching

RFC 10008 §2.7 is explicit: the cache key must incorporate the request content.

Shared HTTP caches have always keyed on method + URL. With QUERY, many different bodies hit the same URL:

QUERY /search  { "q": "cats" }   -> cats
QUERY /search  { "q": "dogs" }   -> dogs

A method+URL cache would serve the cats response to the **dctness and security bug — the RFC's Security Considerationscalls it out.

Doing it right: conservative body normalization

You want two things in tension:

{"a":1,"b":2} and { "b":2, "a":1 } mean the same thing → same key (a hit).
{"q":"cats"} and {"q":"dogs"} differ → *different keys

The key insight is an asymmetry: a false miss is harmle is a bug (wrong data served). So every normalization must beprovably meaning-preserving*, and when in doubt you normalize less*.

Safe for JSON: whitespace, object key order, string escape forms. NOT safe: merging numeric literals (JSON.parse("9007199254740993") returns ...992 — a
silent collision), guessing on duplicate keys, or normalizing ctand.

Show me the code

import express from "express";
import { queryable, QueryCache } from "http-queryable/express";

const app = express();
app.use(queryable({ cache: new QueryCache() }));
app.query("/search", (req, res) => res.json(search(req.body)));
app.listen(3000);

curl -X QUERY /search -d '{"q":"cats"}'      # MISS -> cats
curl -X QUERY /search -d '{ "q" : "cats" }'  # HIT  (same meaning)
curl -X QUERY /search -d '{"q":"dogs"}'      # MISS -> dogs

That third line is the whole point: a different body gets the cr a stale hit.

It handles the rest too

Accept-Query negotiation, Content-Location "switch to GET" flow CORS-safelisted), an isomorphic client with safe auto-retry,and Fastify + raw http adapters over the same core.

Try it

Node >= 22 (where QUERY lands in http.METHODS).

npm install http-queryable

Repo + docs: https://github.com/hardik-goel/http-queryable — stars and edge-case bug reports welcome.

Agent Mesh: Solving M2M,A2A payments

Wed, 19 Aug 2026 04:29:21 +0000

Building the Agent Mesh: Solving Machine-to-Machine Payments (x402), Discovery, and Swarm Telemetry

Hey Agents,

Most multi-agent systems today hit the same structural wall: they rely on human-native rails.

When Agent A needs compute, data, or tool execution from Agent B, it shouldn’t require human intervention, manual API key provisioning, or credit card subscriptions. Autonomous agents need machine-native economics, decentralized mesh discovery, and real-time swarm telemetry.

We built ScriptMaster Labs as an infrastructure layer designed specifically for autonomous agent swarms and M2M coordination.

The Stack: What We’re Solving. https://pypi.org/project/langchain-citemesh/

Machine-Native Economic Rails (x402 Protocol)

Direct agent-to-agent micro-transactions and payment streams.

Allows autonomous agents to buy and sell tool calls, data feeds, and compute per-request without manual billing friction.

Autonomous Agent Mesh & Swarm Memory

Decentralized interconnects and low-latency telemetry routing for multi-agent swarms.

Distributed state and memory sync across isolated execution environments.

Model Context Protocol (MCP) & Discovery Beacons

Native MCP server implementations optimized for Smart Order Routers (SOR).

Machine-readable beacons (Agent Magnet Beacons & Intention Market Protocols) for programmatic service discovery.

Reputation & Verification Telemetry

Machine-verifiable scoring, telemetry grading, and trust metrics for autonomous actors.

Deterministic execution frameworks to eliminate hallucinated agent interactions.

How to Connect

If you're building autonomous swarms, hosting MCP tools, or experimenting with M2M micro-economies, explore the ecosystem at scriptmasterlabs.com.

Curious to hear from other builders here: What are you currently using for agent-to-agent payments and swarm state coordination?

The HTTP QUERY Method: Safe Reads with a Body

Mon, 20 Jul 2026 09:21:55 +0000

If you've ever built a search endpoint, you've hit this wall. Your query has filters, sort orders, a nested set of facets, maybe a geo bounding box. It doesn't fit in a URL, and cramming it into query string params is ugly and fragile. So you reach for POST /search, send the whole thing as a JSON body, and quietly accept that you've just lied about what the request does. It's not creating anything. It's a read. But POST is the only tool that lets you attach a body without fighting the platform.

That gap finally got filled. In June 2026 the IETF published RFC 10008, which defines the HTTP QUERY method: a new verb built for exactly this case.

The two bad options

Every read that needs structured input has been stuck choosing between GET and POST, and both are wrong in their own way.

GET is the semantically correct choice. It's safe (the client isn't asking to change anything), it's idempotent (retrying it is fine), and it's cacheable. The problem is the body. RFC 9110 is explicit that content in a GET request has no defined semantics, and sending one may cause some implementations to reject the request. So your query has to live in the URI, where you run into unknown length limits across proxies and servers, encoding overhead, and the query landing in access logs and browser history.

POST solves the body problem and creates a new one. It carries any payload you want, but it's neither safe nor idempotent by definition. Intermediaries won't cache it, clients won't retry it automatically after a dropped connection, and anything inspecting traffic has to assume the request might have side effects. You get the body, you lose everything that made the request honest.

QUERY is the missing third option: a method that carries a body and keeps the semantics of a read.

What QUERY actually is

The spec, authored by Julian Reschke, James Snell, and Mike Bishop, describes it in one sentence:

A QUERY requests that the request target process the enclosed content in a safe and idempotent manner and then respond with the result of that processing.

So a QUERY request looks like this:

QUERY /products HTTP/1.1
Host: example.com
Content-Type: application/json
Accept: application/json

{
  "filters": { "category": "keyboards", "inStock": true },
  "sort": [{ "field": "price", "order": "asc" }],
  "page": { "size": 20 }
}

The three properties that matter:

It's safe and idempotent. The client isn't requesting a state change, and the request can be retried or repeated without worrying about partial effects. This is what POST could never promise.

It's cacheable. A cache is allowed to store the response and use it to satisfy later QUERY requests. The catch is that the cache key has to include the request content, not just the URI, since the body is what distinguishes one query from another. Two QUERYs to the same URL with different bodies are different requests. In practice, getting a CDN to key on anything beyond the URI is its own fight, as I found out trying Accept-based content negotiation on Cloudflare.

The response isn't a representation of the URI. Unlike GET, where the response is the resource at that URL, a QUERY response is the result of running your query over some data scoped to the target. GET /products returns the products resource; QUERY /products returns whatever your query selected from it.

The details that bite

A few rules are worth knowing before you wire this up.

Content-Type is mandatory. The server MUST reject the request if the Content-Type field is missing or inconsistent with the body. In practice you'll see a 400 for a missing media type, a 415 Unsupported Media Type for one the server doesn't handle, and a 422 Unprocessable Content when the body parses fine but doesn't make sense as a query.

There are two response headers that trip people up because they sound alike:

Content-Location points at a resource representing the results of this query. A client can GET that URL later to fetch the same results again.
Location points at a resource representing the query itself. A client can GET that URL to re-run the query without resending the body, which is handy for turning a heavy query into a shareable link.

Results points to the answer; Location points to the question.

The spec also nudges you away from HTTP range requests for pagination. Range semantics technically apply, but most query formats already have their own paging built in (think SQL's FETCH FIRST), and that's the mechanism you should reach for.

Can you use HTTP QUERY today?

On the client, yes, already. The Fetch API and libraries like axios accept arbitrary method strings, so nothing is stopping you from sending one right now:

const res = await fetch("/products", {
  method: "QUERY",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ filters: { category: "keyboards" } }),
});

One gotcha before you do: pass the method in uppercase. fetch only normalizes the case of a fixed set of methods (DELETE, GET, HEAD, OPTIONS, POST, PUT), and QUERY isn't on it. Write method: "query" and it goes out verbatim, which a case-sensitive server will reject.

The friction is everywhere else in the stack. QUERY isn't a CORS-safelisted method, so cross-origin QUERY requests trigger a preflight OPTIONS. Your server has to answer it with Access-Control-Allow-Methods: QUERY or the browser blocks the real request. And anything that whitelists methods will reject QUERY until you tell it not to: reverse proxies, WAFs, API gateways, limit_except blocks in nginx. The method passing through the wire is the easy part; the config that guards the wire is where you'll spend your time.

Framework and server support is still landing. New HTTP methods don't come around often. The last one most people reached for was PATCH back in 2010, so the ecosystem moves slowly. Expect native routing helpers and middleware to fill in over the next couple of years rather than overnight.

Should you rush to switch?

Probably not, and there's no need to. Your POST /search endpoints work and aren't going anywhere. QUERY is the more correct tool, not an urgent migration.

What it does give you is a real answer to a question we've been hacking around for years. It's the same pattern the Cross-Origin Storage API and WebMCP got right: the platform finally naming something we'd been faking. When you're designing a new read endpoint that needs a structured body, you now have a method that says exactly what it means: this is a safe, repeatable, cacheable read, and here's the query in the body where it belongs. That's worth reaching for on the next thing you build, even if the old endpoints stay put.

HTTP Status Codes Explained with a Resturant Analogy

Wed, 15 Jul 2026 05:29:10 +0000

You order food.The kitchen responds.That's literally what HTTP is - and once you get this, servers will never feel mysterious again.

A little backstory

I'm a newcomer to web development, and for the longest time, servers and HTTP felt like some dark magic I wasn't supposed to understand yet. That changed when I started working on my ASCII-ART-WEB project at Zone01.

The project required me to build an actual HTTP server from scratch — handling requests, sending responses, setting the right status codes. Suddenly all of this wasn't theoretical anymore. I had to understand it. And when it clicked, it clicked hard.

This article is me passing that click on to you, using the analogy that finally made it stick.

The internet is a restaurant

Seriously. Every time you type a URL into your browser, you're basically sitting at a table and calling a waiter over.

HTTP stands for HyperText Transfer Protocol. It's just the agreed-upon language that lets your browser and the server talk to each other. Nothing more mysterious than that.

Every page load is a tiny round-trip conversation:

Browser → [HTTP request] → Server → [HTTP response + status code] → Browser renders the page

Step by step:

You type a URL and hit Enter
Your browser sends an HTTP request to the server at that address
The server receives the request and processes it
The server sends back an HTTP response — which includes the data (a webpage, an image, JSON, etc.) and a status code
Your browser reads the status code, then renders the page

That status code is the kitchen's way of telling the waiter how the order went before the food even leaves the counter.

What an HTTP request actually looks like

When your browser asks for a page, it sends something like this under the hood:

GET /menu HTTP/1.1
Host: restaurant.com
Accept: text/html

And the server replies:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 3456

<!DOCTYPE html>
...

That 200 at the top? That's the status code. It's the first thing the browser checks.

The four status codes every dev must know

There are over 60 official HTTP status codes, but these four will cover 90% of what you encounter day-to-day.

200 — OK

"The food arrived hot and exactly as ordered."

The happy path. The server found what you asked for, processed everything correctly, and sent it back. This is what you want to see on every request.

400 — Bad Request

"You ordered in a language the kitchen doesn't understand."

This means the request itself was broken — maybe it was missing required data, had invalid formatting, or sent something the server just can't parse. It's a client-side error, meaning the problem is in the request you sent, not the server.

404 — Not Found

"We checked the whole fridge. That dish doesn't exist here."

The server is working fine, but the specific thing you asked for — that URL, that file, that route — simply doesn't exist. Classic example: you mistype a URL, or someone deleted a page that used to exist.

500 — Internal Server Error

"The oven exploded. It's not your fault — something broke inside the kitchen."

The server tried to handle your request but something went wrong in its own code. This is a server-side error. As the user, you did nothing wrong. As the developer, this is where you open your logs and start debugging.

The golden rule of status codes

4xx = The customer's fault
5xx = The kitchen's fault

Memorise this. When you're debugging and you see a 4xx, look at what you're sending. When you see a 5xx, look at what the server is doing with it.

The full status code family tree
Status codes are grouped by their first digit:
1xx-Informational-"Hold on,still cooking.."
2xx-Success-"Here's your food,enjoy"
3xx-Redirection-"Wrong table-they're at table 7 now"
4xx-Client error-"Your order is the problem"
5xx-Server error-"The kitchen is having a moment"

A few other useful ones you'll bump into:

201 Created — used in APIs when something new was successfully created (like a new user account)
301 Moved Permanently — the URL has changed forever, the server redirects you
401 Unauthorized — you need to log in first
403 Forbidden — you're logged in but you're not allowed to access this
422 Unprocessable Entity — the server understood your request but couldn't process it (common in form validation)

How ASCII-ART-WEB helped me understand all of this

When I was working on the ASCII-ART-WEB project at Zone01, I had to build an HTTP server in Go that:

Received a POST request with text from a web form
Converted that text into ASCII art using a banner file
Sent back the result as an HTTP response

At first, I was just copying status codes without understanding them. Then I hit a bug: my server was sending 200 OK even when the input was invalid.

A user would send an empty form — technically a bad request — and my server was responding like everything was fine. That's when the restaurant analogy hit me: if a customer orders nothing, the kitchen shouldn't just send back an empty plate with a smile. It should say "400 — your order doesn't make sense."

Once I fixed that, my server started behaving like a real server:

go// If the form input is empty, respond with 400
if userText == "" {

http.Error(w, "400 - Bad Request: input cannot be empty", http.StatusBadRequest)
return

}

// If the banner file doesn't exist, respond with 404
if _, err := os.Stat(bannerFile); os.IsNotExist(err) {

http.Error(w, "404 - Banner file not found", http.StatusNotFound)
return

}

// If something unexpected breaks, respond with 500
http.Error(w, "500 - Internal Server Error", http.StatusInternalServerError)

Suddenly HTTP wasn't abstract theory. Every status code had a job. Every response had a reason. The restaurant wasn't just an analogy anymore — it was the mental model I used every time I wrote a handler.

Try it yourself right now

Open your browser, press F12, and go to the Network tab. Reload any webpage.

Every single row you see is an HTTP request, with its status code right there in the Status column. Watch the 200s flood in as the page loads. Try visiting a broken URL and watch the 404 appear. This is how real developers debug every single day — and seeing it live is the fastest way to make everything in this article click.

Wrapping up

HTTP is just two sides talking to each other — a customer and a kitchen. Status codes are how the kitchen reports back. Once you stop thinking of them as mysterious numbers and start thinking of them as kitchen updates, the whole web starts making more sense.

If you're working on any project that touches a server — even a small one like ASCII-ART-WEB — I'd genuinely encourage you to try building a basic HTTP handler yourself. Reading about status codes is one thing. Returning the wrong one and watching your app break in a confusing way is what actually teaches you.

Thanks for reading! If you found this helpful or you're also a newcomer grinding through your first server project, drop a comment — I'd love to hear what you're building.Alsoo don't forget to fllow and connect with me on linked in @mayan okul

Status:200 OK.This article:served

The New HTTP QUERY Method

Tue, 07 Jul 2026 18:50:12 +0000

That gap finally got filled. In June 2026 the IETF published RFC 10008, which defines the HTTP QUERY method: a new verb built for exactly this case.

The two bad options

Every read that needs structured input has been stuck choosing between GET and POST, and both are wrong in their own way.

QUERY is the missing third option: a method that carries a body and keeps the semantics of a read.

What QUERY actually is

The spec, authored by Julian Reschke, James Snell, and Mike Bishop, describes it in one sentence:

A QUERY requests that the request target process the enclosed content in a safe and idempotent manner and then respond with the result of that processing.

So a QUERY request looks like this:

QUERY /products HTTP/1.1
Host: example.com
Content-Type: application/json
Accept: application/json

{
  "filters": { "category": "keyboards", "inStock": true },
  "sort": [{ "field": "price", "order": "asc" }],
  "page": { "size": 20 }
}

The three properties that matter:

It's safe and idempotent. The client isn't requesting a state change, and the request can be retried or repeated without worrying about partial effects. This is what POST could never promise.

The details that bite

A few rules are worth knowing before you wire this up.

There are two response headers that trip people up because they sound alike:

Content-Location points at a resource representing the results of this query. A client can GET that URL later to fetch the same results again.
Location points at a resource representing the query itself. A client can GET that URL to re-run the query without resending the body, which is handy for turning a heavy query into a shareable link.

Results points to the answer; Location points to the question.

Can you use HTTP QUERY today?

On the client, yes, already. The Fetch API and libraries like axios accept arbitrary method strings, so nothing is stopping you from sending one right now:

const res = await fetch("/products", {
  method: "QUERY",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ filters: { category: "keyboards" } }),
});

Should you rush to switch?

Probably not, and there's no need to. Your POST /search endpoints work and aren't going anywhere. QUERY is the more correct tool, not an urgent migration.

What it does give you is a real answer to a question we've been hacking around for years. When you're designing a new read endpoint that needs a structured body, you now have a method that says exactly what it means: this is a safe, repeatable, cacheable read, and here's the query in the body where it belongs. That's worth reaching for on the next thing you build, even if the old endpoints stay put.

What Is HTTP & HTTPS ?

Fri, 05 Jun 2026 09:00:45 +0000

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

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

What Is HTTP?

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

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

Key characteristics:

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

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

How HTTP Works: The Request/Response Cycle

Every HTTP interaction follows a strict two-step pattern.

Step 1 — The Request

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

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

It has three parts:

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

Step 2 — The Response

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

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

{
  "id": 123,
  "name": "Anne",
  "email": "anne@example.com"
}

It has three parts too:

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

HTTP Status Codes

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

![[Pasted image 20260529223910.png]]

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

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

Making HTTP Requests in Go

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

package main

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

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

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

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

You can also inspect headers directly:

fmt.Println(resp.Header.Get("Content-Type"))

What Is HTTPS?

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

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

HTTPS gives you three guarantees:

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

How HTTPS Works: The TLS Handshake

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

Here is a simplified view of the steps:

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

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

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

4. BOTH SIDES       Derive the same symmetric session key.

5. ENCRYPTED        All further communication is encrypted.
   CHANNEL ✓

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

HTTP vs HTTPS

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

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

Making HTTPS Requests in Go

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

package main

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

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

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

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

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

package main

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

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

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

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

Summary

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

I Was Tired of Installing API Tools Just to Test One Endpoint — So I Found Something Better

Wed, 03 Jun 2026 18:41:12 +0000

Let me paint you a picture.

It's 11 PM. You're integrating a third-party payment API into your app. The documentation is decent, but something isn't working — you keep getting a 401 Unauthorized back, and you have no idea if it's your token, your headers, or just the universe conspiring against you.

Your options? Fire up Postman (which you haven't opened in three weeks and now wants to update), install Insomnia (if you remember your account password), or try writing a quick curl command in the terminal — knowing full well you'll mess up the escaping on the JSON body and spend another 20 minutes Googling why.

There's a fourth option. One that requires zero installs, zero accounts, and zero patience for setup.

But before we get there — let's actually talk about REST APIs, because if you're new to this world, a lot of it can feel unnecessarily mysterious.

What Even Is a REST API?

Here's the non-textbook version: a REST API is just a way for two systems to talk to each other over the internet using standard web rules.

When you open Instagram and your feed loads — that's your app making an API call to Instagram's servers. When you book a flight and your seat gets confirmed — that's an API call going to the airline's backend. When Slack notifies you of a new message on your phone — you guessed it.

REST stands for Representational State Transfer, which sounds incredibly academic and not particularly useful to know. What matters is the practical part: REST APIs use regular HTTP (the same protocol your browser uses), they deal in resources (think: users, orders, products), and they communicate mostly in JSON — a format that looks like this:

{
  "user": "sadiq",
  "status": "active",
  "plan": "pro"
}

Clean. Human-readable. Easy to work with.

The other thing you need to know is that REST APIs use HTTP methods to express intent:

GET — "Give me something." Fetching a list of users, loading a profile, retrieving an order.
POST — "Create something new." Submitting a form, registering an account, placing an order.
PUT — "Replace this thing entirely." Updating a user's full profile.
PATCH — "Just change this one part." Updating only the email address on a profile.
DELETE — "Get rid of this." Removing a record.

These five methods cover about 99% of what you'll encounter in real-world API work. The other two — HEAD and OPTIONS — are more behind-the-scenes, usually used for checking if a resource exists or for CORS preflight checks.

The Problem With Testing APIs

Here's something nobody talks about enough: testing APIs is just hard enough to be annoying.

It's not hard like writing a compiler or implementing a sorting algorithm. It's hard in a friction-filled, setup-heavy, "why am I spending 20 minutes on this" kind of way.

If you're a backend developer, you probably have curl muscle memory by now. But curl is unforgiving — one misplaced quote or escaped character and your beautifully crafted JSON body turns into garbage. And reading curl output when something goes wrong? Not exactly a pleasant experience.

Postman is the gold standard for a lot of teams, and for good reason — it's powerful. But powerful also means complex. Collections, environments, workspaces, team sync — it's a lot when you just want to fire off a quick request to see if an endpoint returns what it's supposed to. There's also the matter of it being a desktop app you need to install, update, and sometimes log into.

The other issue that catches developers off-guard — especially those newer to frontend work — is CORS.

CORS (Cross-Origin Resource Sharing) is a browser security feature that blocks your JavaScript from calling APIs on different domains unless the API explicitly says "yes, this domain can talk to me." It exists for genuinely good reasons (preventing malicious websites from making requests on your behalf), but it's also the source of an enormous amount of confusion and pain.

You'll write what looks like perfect code. You'll test it. You'll get a wall of red text in your browser console that says something like Access to fetch at 'https://api.example.com' from origin 'http://localhost:3000' has been blocked by CORS policy. And you'll wonder if you've done something horribly wrong.

You haven't. The API just doesn't allow browser-based requests from your origin. It'll work fine server-to-server — which is exactly why a server-side testing tool is so much more useful than a browser-based one.

Meet the Tool That Actually Fixes This

There's a free online REST API tester over at sadiqbd.com — specifically the REST API Checker — and honestly, it's become one of those tools I didn't know I needed until I started using it.

The concept is simple: you paste in your API URL, choose your method, add any headers or a request body, and hit Send. Within seconds you get back the full response — status code, response headers, response body (pretty-printed if it's JSON), and the time it took.

What makes it different from just opening your browser's Network tab is the server-side proxying. When you use this tool, the request doesn't come from your browser — it comes from their server. That completely bypasses CORS. It doesn't matter if the API has restrictive CORS headers or none at all. You'll get the real response, every time.

Let me walk through what it actually supports:

HTTP Methods: GET, POST, PUT, PATCH, DELETE, HEAD, and OPTIONS. Every method you'll realistically need.

Custom Headers: Add as many as you need. Authorization tokens, Content-Type overrides, custom API keys — any header the API expects, you can set it. The Authorization header field especially comes in handy when you're debugging authentication: Bearer your-token-here goes in just like you'd set it in code.

Request Body Formats: Three options — JSON (which auto-sets Content-Type: application/json), raw (for XML, plain text, or anything else), and multipart form-data (for file uploads). This is actually comprehensive enough to cover most real-world API testing scenarios.

Response Details: You get the status code, response time, body size, all response headers, and the formatted body. If the API returns JSON, it's automatically prettified so you can actually read it.

Real Scenarios Where This Saves Time

Scenario 1: You're integrating a new API and want to verify it works before writing any code.

This is the fastest use case. Copy the example request from the documentation, paste it in, run it. If it returns what the docs say it should, you know the API is working and your credentials are valid. Now you can write code with confidence.

Scenario 2: Something's broken in production and you need to isolate whether it's your code or the API.

Hit the API directly from the tester with the same payload your code sends. If it works there but not in your app, the bug is in your code. If it fails there too, the API is the problem. Five seconds of testing that would have taken you 20 minutes to debug otherwise.

Scenario 3: You're getting a 400 Bad Request and have no idea why.

This is where the response body matters. Most well-designed APIs return a JSON error object explaining what went wrong — missing field, wrong data type, invalid value. The pretty-printed response makes this readable immediately. Common culprits: missing required fields, wrong data types, or subtly malformed JSON (a trailing comma that's valid in JavaScript but not in strict JSON parsers).

Scenario 4: You're testing a webhook.

Webhooks are notoriously painful to debug. With this tool, you can replay a webhook payload to your endpoint and see exactly what it returns — useful for reproducing intermittent failures or testing your error handling.

Scenario 5: Comparing staging vs. production.

Swap the URL, keep everything else the same. If staging returns something different from production, you've found your environment drift. This kind of quick comparison is surprisingly hard to do cleanly with other tools.

A Few Things Worth Knowing

On API key safety: The tool doesn't store your request bodies, headers, or responses. That said, for genuinely sensitive production credentials — the ones that control real money or user data — it's wise to use scoped test keys or short-lived tokens. Not because this tool is untrustworthy, but because that's just good security hygiene regardless of what tool you're using.

On private/internal APIs: Since requests are made server-side, they need to reach a publicly accessible URL. Private IPs and loopback addresses (localhost, 192.168.x.x, etc.) are blocked for security reasons. For internal APIs, you'd need a tunneling tool like ngrok to expose them temporarily.

On file uploads: The multipart form-data option supports file attachments up to 5 MB each. That covers most practical file upload API testing scenarios — image upload endpoints, document imports, that kind of thing.

Beyond REST API Testing

While you're on sadiqbd.com, it's worth knowing the site is actually a full toolkit for developers and beyond. The developer section alone has a JSON Formatter (genuinely one of the most-used tools when working with APIs), a JWT Decoder (paste in any JWT and instantly see the header, payload, and expiry), a Regex Tester, Hash Generator, Base64 Encoder/Decoder, and more.

There are also internet tools for DNS lookups, SSL checking, HTTP header inspection, and port scanning — the kind of things you end up Googling every few weeks and wishing were in one place.

It's the sort of site that earns a browser bookmark pretty quickly.

The Bigger Picture

Here's what I actually think about when I look at a tool like this: the best developer tools are the ones that collapse friction.

The gap between "I want to test this API" and "I have my test result in front of me" should be as small as possible. Every minute spent setting up a client, remembering a password, updating software, or wrestling with a curl command is a minute not spent on the actual problem you're trying to solve.

The REST API Checker on sadiqbd.com doesn't do everything Postman does. It doesn't have saved collections or team collaboration or automated test suites. But it does the thing you need most of the time — send a request, see the response — with literally zero friction. Open a tab, paste a URL, click Send.

That's it.

For the quick tests, the late-night debugging sessions, the "let me just verify this works before I write the integration" moments — it's hard to beat.

Wrapping Up

REST APIs are everywhere. Understanding them — even at a surface level — makes you dramatically more effective as a developer, whether you're building backends, working on frontend integrations, or just trying to make sense of why something isn't working.

And having a fast, reliable, no-fuss way to test them? That's not a luxury. It's just practical.

Bookmark sadiqbd.com/developer/rest-api-checker. You'll use it more than you expect.

Found this useful? The full suite of developer tools — JSON formatter, JWT decoder, regex tester, and more — lives at sadiqbd.com.

HTTP Status Codes You Never Knew Existed

Fri, 03 Apr 2026 06:11:29 +0000

Everyone knows 200 OK, 404 Not Found, and 500 Internal Server Error — but HTTP has over 60 status codes, and some of them are genuinely useful yet barely talked about.

Here are some hidden gems:

418 I'm a Teapot ☕
Yes, this is real. Originally an April Fools' joke (RFC 2324), but it's in the spec. Some devs use it to reject requests that "shouldn't" hit a server.

207 Multi-Status
Returns multiple status codes in one response body. Super useful for bulk operations — e.g., when you upload 10 files and some succeed while others fail.

409 Conflict
More specific than 400 Bad Request. Use this when a request conflicts with the current state — like trying to create a username that already exists.

410 Gone
Different from 404. Use 410 when a resource used to exist but has been permanently deleted. Great for SEO — tells crawlers to stop indexing it.

425 Too Early
Tells the client not to retry yet because the server isn't ready to process it safely. Useful in early-data TLS scenarios.

103 Early Hints
Sent before the final response to let the browser start preloading resources. Can noticeably improve page load performance.

Which status codes do you actually use in your projects? Drop them below

HTTP vs HTTPS: A Practical Guide for Developers

Tue, 10 Feb 2026 19:35:17 +0000

HTTP vs HTTPS: A Practical Guide for Developers

When working on real-world projects, one mistake beginners often make is ignoring website security. One of the simplest but most important decisions is choosing HTTPS instead of HTTP.

This short guide explains the difference in a practical, developer-focused way.

HTTP: Why It’s Not Safe

HTTP sends data between the browser and server in plain text.

That means:

Login credentials can be intercepted
Form data is exposed
Vulnerable to Man-in-the-Middle (MITM) attacks

This makes HTTP unsuitable for any production-level project.

HTTPS: The Secure Standard

HTTPS secures communication using SSL/TLS encryption.

In practice, HTTPS:

Encrypts request and response data
Protects passwords and user input
Verifies server identity
Prevents data tampering

Modern browsers trust HTTPS — and warn users about HTTP.

Quick Visual Reference

HTTP vs HTTPS comparison image

HTTP vs HTTPS (Quick Comparison)

Feature	HTTP	HTTPS
Encryption	❌ No	✅ Yes
Security	Low	High
Browser Warning	Yes	No
Suitable for Login Forms	❌	✅

When HTTPS Is Mandatory

Use HTTPS if your project includes:

Login / signup systems
Contact forms
Admin dashboards
Payment or user data

In short: almost every real project.

Final Takeaway

HTTP may work for learning demos, but HTTPS is required for real applications.

If you want your projects to look professional, secure and production-ready — always use HTTPS by default.

#webdev #security #https #Web Security #http #beginners #programming #ReactJS #FullStackDevelopment #WebDevelopment #MuhammadYasir #YasirAwan4831 YasirAwaninfo

Coder Legion - Recent posts tagged http

Debug HTTP 422 API Validation Errors Safely

What HTTP 422 actually tells you

The anti-patterns of error handling

Redacting and bounding output

Verification checklist

HTTP Just Got a New Method After 16 Years—Meet QUERY.

Why Was QUERY Needed?

Why Not Just Use POST?

Meet QUERY

What Does "Idempotent" Actually Mean?

Why This Matters

A Practical Example

What About Spring Boot and Other Frameworks?

Should You Use QUERY Today?

Final Thoughts

Building an HTTP Server From Scratch using TCP.

What Does Raw HTTP Actually Look Like?

1. The HTTP Request Format

2. The HTTP Response Format

Building an HTTP Server from Raw TCP

1. Setting Up the TCP Listener

What is happening here?

2. The Request Lifecycle (handleConnection)

3. Reading the Raw Byte-Stream (pkg/stream)

4. Parsing the Request (pkg/request)

5. Writing the HTTP Response (pkg/response)

6. Testing the Server with curl -v

Making HTTP Better on ESP32

HTTP on ESP32 Isn't Hard. The Unnecessary Work Around It Is.

A Simple Request Can Turn Into a Long Workflow

The Real Cost Isn't HTTP

Memory Predictability Matters on Embedded Devices

Do You Really Need the Entire JSON Response?

Nested Paths, Arrays, and Missing Keys

Reducing Work Means More Than Reducing Memory

Fluent Payloads and Full REST Support

Path and Query Parameters Without String Concatenation

Beyond Primitives: Struct <-> JSON Mapping

Authentication Shouldn't Become Repeated Boilerplate

Extracting Response Headers

Reuse the Client, Not Just the Code

Measuring the Difference

A More Practical Example

But Should You Always Avoid a Full JSON Parser?

When Does This Approach Actually Matter?

The Idea Behind ESP32-HTTP-Client

Final Thoughts

Explore the Project

The HTTP QUERY method (RFC 10008) is here — and caching it correctly is harder than it looks

TL;DR

What is the QUERY method?

The catch nobody talks about: caching

Doing it right: conservative body normalization

Show me the code

It handles the rest too

Try it

Agent Mesh: Solving M2M,A2A payments

The HTTP QUERY Method: Safe Reads with a Body

The two bad options

What QUERY actually is

The details that bite

Can you use HTTP QUERY today?

Should you rush to switch?

HTTP Status Codes Explained with a Resturant Analogy

The New HTTP QUERY Method

The two bad options

What QUERY actually is

The details that bite

Can you use HTTP QUERY today?

Should you rush to switch?

What Is HTTP & HTTPS ?

What Is HTTP?

How HTTP Works: The Request/Response Cycle

Step 1 — The Request

Step 2 — The Response

HTTP Status Codes

Making HTTP Requests in Go

What Is HTTPS?

How HTTPS Works: The TLS Handshake

2. The Request Lifecycle (`handleConnection`)

3. Reading the Raw Byte-Stream (`pkg/stream`)

4. Parsing the Request (`pkg/request`)

5. Writing the HTTP Response (`pkg/response`)

6. Testing the Server with `curl -v`