API Testing Using POSTMAN
What is API?
An API is an interface or communication protocol between a client & a server that intends to simplify the client-side application for a better user experience.
What is a RESTful API?
RESTful APIs follow REST architecture (Representational State Transfer).
# What is URI for End-Point URL?
Basically, API / Endpoint URL is the combination of things like below: {Base URL} + {Resource} + {Path/Query Parameter}
Path Parameter: Path parameters are various parts of the Endpoint URL. They are used to point to a specific resource within the collection. Let’s say a user can be recognized by ID.
Ex: https://www.google.com/images/234123 <—– Path Parameter
Query Parameter: A query parameter is used to sort/filter the resources. Query parameter identified by a question mark “?”
https://www.google.com/search?q=newyork
Resources:
Resources represent API/Collection, which can be accessed from the Server.
Eg: google.com/maps
google.com/search
google.com/images
You can see some basic information to perform API testing. Basically, it’s a client-server architecture. Client sends the request to the server and the server returns the response. You can see some information below:
Methods in API testing
Get Method: When we want to fetch data from the server then, we use the GET method to fetch the data.
POST Method: When we want to create some new resource on the server then, we use the POST method.
PUT Method: When we want to update any existing resource, then we use the PUT method to modify it. If the parameter which we want to update is available, then it modifies that parameter. If that parameter is not available, then it creates that parameter.
PATCH Method: When we want to do a partial update then, we use the PATCH method to update. We pass only that parameter that we want to update, we don’t have to pass a complete payload to update the resource.
Response Codes
1xx informational response – the request was received, continuing process
2xx successful – the request was successfully received, understood, and accepted
200 OK: The actual response will depend on the request method used. The response will contain an entity corresponding to the requested resource in a GET request.
201 Created: The request has been fulfilled, resulting in the creation of a new resource.
202 Accepted: The request has been accepted for processing but has not been completed.
3xx redirection – further action needs to be taken in order to complete the request 4xx client error – the request contains bad syntax or cannot be fulfilled.
400 Bad Request: The server cannot or will not process the request due to an apparent client error (e.g., malformed request syntax, size too large, invalid request message framing, or deceptive request routing).
401 Unauthorized: Similar to 403 Forbidden, but specifically for use when authentication is required and has failed or has not yet been provided.
403 Forbidden: The request contained valid data and was understood by the server, but the server refuses action. This may be due to the user not having the necessary permissions for a resource.
404 Not Found: The requested resource could not be found but may be available in the future.
5xx server error: The server failed to fulfill an apparently valid request.
500 Internal Server Error: A generic error message, given when an unexpected condition is encountered and no more specific message is suitable.
501 Not Implemented: The server either does not recognize the request method or lacks the ability to fulfill the request. Usually, this implies future availability (e.g., a new feature of a web-service API).
502 Bad Gateway: The server was acting as a gateway or proxy and received an invalid response from the upstream server.
503 Service Unavailable: The server cannot handle the request (because it is overloaded or down for maintenance). Generally, this is a temporary state.
504 Gateway Timeout: The server was acting as a gateway or proxy and did not receive a timely response from the upstream server.
What are all validations done while performing API Testing?
Status code: – It validates whether API’s returning the correct status code or not. The 201 status code should be replaced when any resource is created, 400 for bad requests, 500 for internal server error, 401 for unauthorized access, etc.
JSON Schema: – if we are working with rest assured, so as per business logic, sometimes we need to validate whether that JSON schema is correct or not.
Error messages: – In case of a negative scenario, we should get appropriate error messages with an error code like 400 in case of a bad request.
Response: – In the case of a happy path (positive scenarios), we validate the response that response values are expected values or not.
Header: – We can also validate headers, but it depends on the requirement.
Response time: – We can validate the response time of the API. Response time is the time that is taken by the server to validate API requests and then provide responses in return.
Difference between HTTP and HTTPs: HTTP stands for Hypertext Transfer Protocol,
a protocol and syntax for presenting information – used for transferring data over a network. Most information sent over the Internet, including website content and API calls, uses the HTTP protocol.
The S in HTTPS stands for “secure.” HTTPS uses TLS (or SSL) to encrypt HTTP requests and responses, so in the example above, instead of the text, an attacker would see a bunch of seemingly random characters.
“If a website uses HTTP instead of HTTPS, all requests and responses can be read by anyone who is monitoring the session. Essentially, a malicious actor can just read the text in the request or the response and know exactly what information someone is asking for, sending, or receiving.”
