Understanding Common HTTP Response Codes

When you start working with REST APIs, one of the first things you need to understand is how servers communicate back to you. Every time you send an HTTP request, the server replies with a numeric status code that tells you whether the request succeeded, failed, or something in between. These are called HTTP response codes, and knowing the common ones is essential for both the CCNA DevNet exam and real-world automation work.

How HTTP Response Codes Are Organized

HTTP response codes are three-digit numbers grouped into five classes based on the first digit. Here is a quick breakdown of what each range means:

• 1xx (Informational): The request was received and processing is continuing.
• 2xx (Success): The request was received, understood, and accepted.
• 3xx (Redirection): Further action is needed to complete the request.
• 4xx (Client Error): The request contains bad syntax or cannot be fulfilled by the server.
• 5xx (Server Error): The server failed to fulfill a valid request.

For the CCNA DevNet exam and everyday API work, you will mostly encounter codes in the 2xx, 4xx, and 5xx ranges. Let's walk through the ones you absolutely need to know.

The Most Common HTTP Response Codes

200 OK

This is the response code you want to see. A 200 OK means your request was successful and the server returned the expected data. For example, if you send a GET request to a network device's REST API to retrieve interface information, a 200 response means everything worked correctly and the body of the response will contain your data.

201 Created

A 201 Created response is returned when a POST request successfully creates a new resource on the server. If you push a new configuration object to a controller via API, a 201 is the success confirmation you are looking for.

204 No Content

A 204 No Content response means the request succeeded, but there is nothing to return in the body. This is common with DELETE requests. The resource was removed, the server is confirming success, and there is simply nothing left to send back.

400 Bad Request

A 400 Bad Request tells you that your request was malformed. This usually means there is a syntax error in your JSON payload, a missing required field, or an invalid parameter. The problem is on your end, so check your request carefully before retrying.

401 Unauthorized

A 401 Unauthorized response means authentication failed. Either you forgot to include credentials, your token has expired, or your credentials are incorrect. This is a common one to see when first setting up API calls against platforms like Cisco DNA Center or APIC-EM.

403 Forbidden

Unlike 401, a 403 Forbidden response means the server understood your request and knows who you are, but you do not have permission to perform that action. Authentication passed; authorization did not.

404 Not Found

The famous 404 Not Found code means the resource you requested does not exist at that URL. This could mean you have a typo in the endpoint path, or the resource was deleted. Double-check your URL structure and verify the resource actually exists.

500 Internal Server Error

A 500 Internal Server Error is the generic server-side failure code. This means something went wrong on the server's end, not with your request. It could be a bug in the API, a misconfiguration on the server, or a temporary outage. If you keep seeing 500 errors, check the server logs or contact the API owner.

Seeing Response Codes in Practice

When you make API calls in Python using the requests library, you can easily check the status code like this:

import requests

url = "https://sandboxdnac.cisco.com/dna/system/api/v1/auth/token"
response = requests.post(url, auth=("devnetuser", "Cisco123!"))

print(response.status_code)

if response.status_code == 200:
    print("Success! Token received.")
elif response.status_code == 401:
    print("Authentication failed. Check your credentials.")
else:
    print(f"Unexpected response: {response.status_code}")

This kind of conditional logic based on response codes is a fundamental pattern in any network automation script. Rather than assuming success, always check the status code before processing the response body.

What's Next

Now that you understand what HTTP response codes mean and how to handle them in your code, the next natural step is exploring the structure of the data those responses carry. In the next post, we will dig into JSON and XML data formats, specifically how API responses are structured and how to parse that data in Python to extract the information you actually need.