Minimum Check list of Manual API Testing:

What is API? Why API?

API (Application Programming Interface):
An API defines how the software components or elements should interact with each other. APIs can be created using a whole host of different technologies. APIs help facilitates communication between a client and a server.

Why API Testing?

One of the most common ways to see companies benefiting from API monitoring is in production — making sure those live API endpoints are up, fast and returning the data that’s expected. By monitoring production endpoints, you’re in the loop as soon as anything breaks, giving you a critical head start to fix the problem before customers, partners or end-users notice.

 But at this point it may already be too late, as the customers will be unsatisfied and unhappy with their restful API not working or not accessible.

Most companies don’t think about how a failure of one of these interfaces can drastically reduce user experience and increase errors. APIs should be tested alongside other features and functionality.

How to Test APIs?

APIs are tested by doing the following:

• Send calls/commands to the API
• Wait for a response
• Review the log of the system’s response to the call
• Verify that the output matches the expected output values.

While it might seem to make sense to simply send a few calls to the API and see what the response is, it isn’t enough. API testing should be incorporated into the overall test scenarios so they can be replicated for future tests or even future projects.

Stranded REST API standard design way

APIs have become
The very important topic nowadays!

We are working every day with different back-end systems in our different mobile apps and therefore we know about the importance of a clean API design and Good API Testing method.

Restful API now a days most accepted used and popular. Typically we use a RESTful design for our web APIs. Everyone we know that the concept of REST is to separate the API structure into logical resources. Most meaningful and resourceful API patterns they used on REST API.

There are used the HTTP methods GET, DELETE, POST and PUT to operate with the resources. and JSON is the most useful response for API.

( JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language.)

Here we can see the 10 best way to design of the standard REST API:

10 best practices to design a clean RESTful API:

 1. Try to use nouns on the endpoint but no verbs. Like Plays instead of play. Pages instead of page.

2. GET method and query parameters should not alter the state.

Like, Use PUT, POST and DELETE methods instead of the GET method to alter the state. Do not use GET for state changes:

3. If a resource is related to another resource use sub-resources for relations

4. Do not mix up singular and plural nouns. Keep it simple and use only plural nouns for all resources.

5. Hypermedia as the Engine of Application State is a principle that hypertext links should be used to create a better navigation through the API.

6. Use HTTP headers for serialization formats. Both, client and server, need to know which format is used for the communication. The format has to be specified in the HTTP-Header. The Content-Type defines the request format. And Accept defines a list of acceptable response formats.

7. Please try to Provide filtering, sorting, field selection and paging for every collections. It will be beneficial for user and developers both.

• For filtering, Use a unique query parameter for all fields or a query language for filtering.
• For sorting, Use ascending and descending sorting over multiple fields.
• For Field selection, Mobile clients display just a few attributes in a list. They don’t need all attributes of a resource. Give the API consumer the ability to choose returned fields. This will also reduce the network traffic and speed up the usage of the API.
• Paging, Use limit and offset. It is flexible for the user and common in leading databases. The default should be limit=20 and offset=0

8. Make the API Version mandatory and do not release an un-versioned API. Use a simple ordinal number and avoid dot notation such as 2.5.

9. Handle Errors with HTTP status codes. It is hard to work with an API that ignores error handling.

The HTTP standard provides over 70 status codes to describe the return values. We don’t need them all, but there should be used at least amount of 10.

So use status code in every types of error.

200 – OK – Eyerything is working

201 – OK – New resource has been created

204 – OK – The resource was successfully deleted

304 – Not Modified – The client can use cached data

400 – Bad Request – The request was invalid or cannot be served. The exact error should be explained in the error payload. E.g. „The JSON is not valid“

401 – Unauthorized – The request requires an user authentication

403 – Forbidden – The server understood the request, but is refusing it or the access is not allowed.

404 – Not found – There is no resource behind the URI.

422 – Unprocessable Entity – Should be used if the server cannot process the enitity, e.g. if an image cannot be formatted or mandatory fields are missing in the payload.

500 – Internal Server Error – API developers should avoid this error. If an error occurs in the global catch blog, the stracktrace should be logged and not returned as response.

So, Use error payloads, All exceptions should be mapped in an error payload.

10. Use the custom HTTP Header X-HTTP-Method-Override to overrider the POST Method. Try to allow overriding HTTP method:

Some proxies support only POST and GET methods. To support a RESTful API with these limitations, the API needs a way to override the HTTP method.

Thanks. :)