API Status Explained

HTTP status codes communicate the outcome of an API request and play a critical role in how applications handle success, failure, and errors. This page explains commonly used API status codes and their meanings, helping testers and developers understand what each response indicates and how it should be interpreted during testing. Use this reference to quickly identify correct behavior, spot inconsistencies, and improve the reliability of API interactions.

HTTP Status Code 101 — Switching Protocols

When working with APIs, you mostly see response codes like 200 OK, 400 Bad Request, and 500 Internal Server Error. These are straightforward — the server either succeeded or failed.

But some responses are more about how the communication continues than about success or failure. HTTP Status Code 101: Switching Protocols is one of them.

This blog will help you understand:

  • What 101 Switching Protocols means
  • Why APIs use protocol upgrades
  • Real-life use cases
  • What testers should verify
  • How to simulate a 101 response
  • Header-level details (Sec-WebSocket-* explained)

What Does Status Code 101 Mean?

Status Code 101: Switching Protocols indicates that the client requested to change the communication protocol during an HTTP request, and the server agreed.
It’s like starting a regular chat and then saying:

  • “Let’s switch to a video call for better experience.”

If both agree → the communication switches formats without disconnecting.
That’s exactly what happens with HTTP → WebSocket upgrades.

Why Would a Client Request a Protocol Switch?

HTTP is request → response → done.
It is not ideal for real-time applications where both sides need to talk anytime (over a single connection).
Examples:

  • Live chat messaging
  • Live stock & crypto price dashboards
  • Multiplayer game updates
  • GPS location tracking in delivery apps
  • Sports score updates
  • Collaborative editing tools

WebSockets solve this by allowing:

  • Always-on connection
  • Low-latency real-time communication
  • Continuous data streaming

HTTP merely initiates the handshake. WebSockets power the actual real-time updates.

How the 101 Switching Protocols Response Works

Here’s what a WebSocket upgrade request looks like:

Client → Server
GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: abc123==

Server → Client
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: xyz456==

Once the server sends 101,

  • Protocol switches
  • WebSocket communication begins

The server does not finish the transaction here. It simply says: “Yes, let’s continue using a different protocol.”

The Security Headers: Sec-WebSocket-*

Because switching protocols is risky, WebSockets include special headers.

Header Sent By Purpose
Sec-WebSocket-Key Client Random value to verify the request
Sec-WebSocket-Accept Server Hashed version of the key to prove authenticity
Sec-WebSocket-Version Client Supported WebSocket version (13 is standard)
Sec-WebSocket-Protocol Both Optional — negotiate chat v1, chat v2 etc.
Sec-WebSocket-Extensions Both e.g., compression settings

These ensure:
✔ The server actually supports WebSockets
✔ The connection is not accidentally hijacked by intermediaries
✔ Both parties speak the same format

Real-Life Example: Food Delivery App

Imagine you are ordering food on Zomato or Swiggy:

1. You place the order → HTTP request

2.You see live updates of the delivery rider’s location


That live map is powered by:

1. WebSockets

2. Server-Push updates

Without WebSockets:
It would need multiple HTTP polls → slower + costly

So your browser upgrades from:
HTTP → WebSocket → real-time tracking

That moment of switching?
Status Code 101!

What Testers Should Validate for 101

Testing WebSockets is different from testing normal APIs. Here’s a useful checklist:

What to verify Why it matters
Request contains upgrade headers Else server won't switch
Response must be 101 status Successful protocol negotiation
Sec-WebSocket-Accept must match Prevents invalid or insecure connections
Connection stays open after handshake Required for real-time messaging
Data exchange format after switch WebSocket messaging, not JSON HTTP responses
Proper closure behavior WebSocket close codes must be correct

Testing failures:

  • Missing headers → expect 400/426
  • Unsupported version → expect 426 Upgrade Required
  • Server refusing upgrade → 403/404

How to Simulate 101 as a Tester

Most manual testing tools don’t fully support WebSockets. But you can still test the below scenario:

1. Add upgrade headers
2. Send GET request
3. Validate 101 Switching Protocols response


Related topics