Exploring Response Status Code 216: Does it Exist? Can we use it? Any Risks?

Introduction

If you've been building or consuming REST APIs, you get to know the common HTTP Status Codes pretty well. You probably know of 200 OK, 201 Created,202 Accepted, 204 No Content, 400 Bad Request,401 Unauthorized, 403 Forbidden, 404 Page Not Found 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable or 504 Gateway Timeout.

Last Week, as we started our enjoyable Data Engineering classes at LuxDevHQ, we covered HTTP Status Codes in detail and out of curiosity, we asked ourselves, "Does HTTP Status Code 216 even exist?" That is what this article is all about: we'll dive into finding out whether it exists, whether you can use it, and the risks associated with using custom HTTP response status codes.

Below are the crucial HTTP Response Status Codes categories defined from the MDN Docs Website that we covered.

Classes of Responses:

1. Informational responses (100 – 199)
2. Successful responses (200 – 299)
3. Redirection messages (300 – 399)
4. Client error responses (400 – 499)
5. Server error responses (500 – 599)

We later asked ourselves some questions about the whole process of coming up with these status codes, registering them and making them usable. To explore the whole idea of HTTP Response Status Codes, we'll answer the questions below:

1. Who defines HTTP Response Status Codes?
2. Does HTTP Status Code 216 exist? Can we use it?
3. Are there any risks using Custom Defined Response Status Codes?

Who defines HTTP Response Status Codes?

After deep research, we found out that status codes are defined and maintained by two Standard Official organizations, namely IETF and IANA:

• IETF(Internet Engineering Task Force)
  It is a standards organization for the Internet responsible for the technical standards of the Internet protocol suite (TCP/IP).

• IANA(Internet Assigned Numbers Authority)
  It is a standards organization that oversees global IP address allocation, autonomous system number allocation, root zone management in the Domain Name System (DNS), media types, and other Internet Protocol–related symbols and Internet numbers.

In addition, individual companies and software developers create their own status codes.

Does HTTP Status Code 216 exist? Can we use it?

After exploring the successful class response(200 - 299), we found that Response Status 216 is Unassigned. See the image below.

We decided to test it in practice by building/running a simple API using Flask Framework and Postman to view the status code.

Blog Endpoint Implementation

from flask import Flask, jsonify

app = Flask(__name__)


@app.route("/")
def home():
    return {"message": "Welcome to this Web Page"}


@app.route("/blog/etl/")
def blog():
    return (
        jsonify({"message": "This response is a non-standard HTTP status code."}),
        216,
    )


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

Response Status Code In Postman

NOTE: The code can be found in this Http Status Code 216 Demo Github Repository.

TakeAway: Response Status Code 216 does exist and can be used, but it appears with the label "UNKNOWN".

Are there any risks using Custom Defined Response Status Codes?

Yes, there are risks associated with using non-standard HTTP Status codes. Some of them include:

1. Client Misinterpretation
   Most clients(mobile apps, systems, browsers, libraries such as requests, etc.) only understand standard HTTP status codes. This may end up treating custom status codes as generic errors, failing to properly map failure or success logic.

2. Break API Expectations
   Using a non-standard status code might be confusing to developers or any other software/related professionals, as many follow the standard defined ones.

3. Proxy, CDN, Monitoring, and Gateway Issues
   Using tools like load balancers for request routing, status codes might get rejected or replaced with the generic responses(200 - 500). For observability/monitoring/orchestration tools, some alerts might not be triggered, resulting in operational risks.

4. Interoperability Issues
   Apart from the common integrations(external systems, etc.), other advanced connections might cause critical fallbacks or failures, which might be critical from a cost and data point of view.

5. Harder API Versioning and Maintenance
   When teams rely on custom status codes, future developers may not understand why they were used, especially in cases where project and code documentation were not covered entirely. This leads to risky refactoring due to undocumented conventions.

Conclusion

APIs are fundamentally about communication, and the more precise your HTTP response status codes, the easier your software/data workflows and sharing become. While you might decide to use custom status codes, it is a good professional practice to use the standard defined HTTP Response status codes.

In case of any questions or comments, feel free to drop them in the comment section👇. Thank you for your time.