Response in Postman

Postman, a popular API testing tool, plays a crucial role in helping developers interact with APIs seamlessly. It serves as an essential tool for efficient testing and debugging. With its user-friendly interface, Postman simplifies the analysis of responses, providing insights into various aspects such as status codes and response body options. This understanding is essential for ensuring successful API testing and debugging processes.

Response in Postman

Let’s talk about the way the API response is visualized in Postman. Firstly, we have status codes, time section, and size are present.

Status Code

In the example above, on the right side, “200 OK” is the status code.

1. Postman provides status information, like “200” in our case.
2. Detailed information about what “200” generally means is available, to have a better understanding of unfamiliar status codes.
3. A string description is also provided; for example, “200” translates to “ok.”

Time

The “524ms” represents the time section.

1. This represents the time taken by the server to respond to the request.
2. Clicking on it reveals a detailed breakdown of events, from socket initialization to response downloading.
3. Useful for primary performance testing of any API.

Size

The next time, size is present (“1.89 KB” in the image).

1. Postman displays the size of both the request and response.
2. It breaks down the size of each component in the request and response.
3. This feature aids in the initial analysis of request and response data.

Body

The body section is nothing where our actual response is displayed. We can see different options available to view the body, Pretty, Raw, Preview, and Visualize.

The difference between these three can be better understood by the following example:

Lets take “amazon” website.

I had made an get call for “https://amazon.com”.

1. Pretty:

• It shows information in a visually pleasing way, using different colors for keys (like ID) and values to make it easy to read.
• Specifically designed for JSON data, it uses colored syntax for a visually appealing response.
• You can collapse individual items or the entire response for simpler interaction.
• The user-friendly design makes it straightforward to understand the data structure, with distinct colors for keys (e.g., id, category) and values (e.g., coffee, true).

Pretty view of Amazon website

2. Raw:

• It presents data in its raw form, without formatting or color, displaying raw JSON.
• This can be challenging to read because of the absence of visual structure.
• However, it is crucial for grasping the unaltered representation of the data.

Raw view of Amazon website

3. Preview:

• Postman makes data easy to view, particularly for formats like images or non-JSON types such as HTML.
• It uses different colors to enhance readability when displaying non-JSON data, improving the overall user experience.

Preview view of Amazon website

4. Visualize:

• The visualization section is helpful when we have added some test scripts and also add some graphics to visualize our test.
• In Postman, the Visualize section displays response data in a user-friendly manner, making it easy to understand.
• It supports different formats like images and uses colors to enhance readability, creating a simple and accessible experience for users.

Visualize section example

Since we do not have any test scripts right now for this request, this section is empty.

Response Headers

The response headers are displayed in tabular format.

Response Header section

Each header is accompanied by an “i” symbol in a circle, offering additional information to enhance understanding. Let’s take a closer look at the content-type header:

Header “i”	Value
Content-Type “i”	application/JSON

Here, the content-type header indicates the media type of the resource. The value, “application/json,” specifies that the content is formatted as JSON. The accompanying symbol provides extra insights into the purpose and meaning of the content-type header.

HTTP Response Status Codes

HTTP response status codes convey the outcome of an HTTP request, organized into five classes:

1. Informational Responses (100 – 199):

Codes	Meaning
100 Continue	Proceed with the request.
101 Switching Protocols	Change in the communication protocol.
102 Processing: The server is processing the request.	The server is processing the request.
103 Early Hints	Used for resource preloading.

2. Successful Responses (200 – 299):

Codes	Meaning
200 OK	Successful request; response contains data.
201 Created	New resource created.
202 Accepted	Acknowledges receipt, awaiting further action.
203 Non-Authoritative Information	Returned metadata may differ from the origin server’s.
204 No Content	No content to send; headers may be useful.
205 Reset Content	Instructs the user agent to reset the document.
206 Partial Content	Used when the client requests only part of a resource.
207 Multi-Status	Conveys information about multiple resources.
208 Already Reported	Used to avoid repeatedly enumerating internal members
226 IM Used	Indicates fulfillment of a GET request with instance manipulations.

3. Redirection Messages (300 – 399):

Codes	Meaning
300 Multiple Choices	Presents multiple response options; the user or agent must choose.
301 Moved Permanently	Informs of a permanent URL change.
302 Found	Indicates a temporary URI change.
303 See Other	Directs the client to fetch the resource from another URI using a GET request.
304 Not Modified	Used for caching; tells the client that the response has not been modified.
305 Use Proxy (Deprecated)	Deprecated due to security concerns.
307 Temporary Redirect	Similar to 302, but the method used in the first request must be retained.
308 Permanent Redirect	Similar to 301, but the method used in the first request must be retained.

4. Client Error Responses (400 – 499):

Codes	Meaning
400 Bad Request	The server can’t process due to a client error.
401 Unauthorized	Authentication is required for access.
402 Payment Required (Experimental)	Reserved for future use.
403 Forbidden	Access is denied; the client’s identity is known.
404 Not Found	The resource does not exist.
405 Method Not Allowed	The server recognizes the method but doesn’t support it.
406 Not Acceptable	Sent when server-driven content negotiation finds no conforming content.
407 Proxy Authentication Required	Similar to 401, authentication is needed by a proxy.
408 Request Timeout	Sent on an idle connection; the server wants to shut down the unused connection.
409 Conflict	Sent when a request conflicts with the current state of the server.
410 Gone	Indicates that the requested content has been permanently deleted.
411 Length Required	The server rejects the request due to the absence of the Content-Length header.
412 Precondition Failed	The client’s indicated preconditions are not met.
413 Payload Too Large	The request entity is larger than the server limits.
414 URI Too Long	The client’s requested URI is longer than the server can interpret.
415 Unsupported Media Type	The media format of the requested data is not supported.
416 Range Not Satisfiable	The range specified in the request cannot be fulfilled.
417 Expectation Failed	The expectation indicated by the Expect header cannot be met.
418 I’m a teapot	The server refuses the attempt to brew coffee with a teapot.
421 Misdirected Request	The request is directed at a server unable to produce a response.
422 Unprocessable Content (WebDAV)	Well-formed request but unable to be followed due to semantic errors.
423 Locked (WebDAV)	The accessed resource is locked.
424 Failed Dependency (WebDAV)	The request failed due to the failure of a previous request.
425 Too Early (Experimental)	The server is unwilling to risk processing a possibly replayed request.
426 Upgrade Required	The server refuses to perform the request using the current protocol but might after the client upgrade.
428 Precondition Required	The origin server requires the request to be conditional.
429 Too Many Requests	The user has sent too many requests in a given time (rate limiting).
431 Request Header Fields Too Large	The server is unwilling to process the request due to large header fields.
451 Unavailable For Legal Reasons	The user agent requested a resource that cannot legally be provided.

5. Server Error Responses (500 – 599):

Codes	Meaning
500 Internal Server Error	The server has encountered a situation it does not know how to handle.
501 Not Implemented	The request method is not supported by the server.
502 Bad Gateway	The server, acting as a gateway, got an invalid response while handling the request.
503 Service Unavailable	The server is not ready to handle the request; often used for maintenance or overload.
504 Gateway Timeout	Given when the server acting as a gateway cannot get a response in time.
505 HTTP Version Not Supported	The HTTP version used in the request is not supported by the server.
506 Variant Also Negotiates	Internal configuration error related to content negotiation.
507 Insufficient Storage (WebDAV)	The method could not be performed due to insufficient storage.
508 Loop Detected (WebDAV)	The server detected an infinite loop while processing the request.
510 Not Extended	Further extensions to the request are required for the server to fulfill it.
511 Network Authentication Required	Indicates that the client needs to authenticate to gain network access.

Conclusion

The Postman API response structure simplifies the communication between clients and servers. It includes crucial elements like status codes, response times, and ways to visualize the response body. This organized approach makes debugging easier, providing developers and testers with essential insights. It improves the efficiency of API testing and development workflows, making it simpler to understand and address communication issues.