how do you implement api

1My PROCESS TO IMPLEMENT API
2First of all
31. Checking API Contract
4An API is essentially a contract between the
5client and the server or between two applications.
6Before any implementation test can begin,
7it is important to make sure
8that the contract is correct. 
9a.	Endpoints are correct,
10b.	Resource correctly reflects the object
11model (proper JSON/XML structure used in response),
12c.	There is no missing functionality
13or duplicate functionality, 
14d.	Relationships between resources
15are reflected in the API correctly. 
16Since I have  verified the API contract,
17I am ready to think of what and how to test. 
182. Creating test cases
19I mostly create the following test case groups:
20a.	Basic positive test (happy paths)
21b.	Extended positive testing with
22optional parameters
23c.	Negative testing with 
24valid input (trying to add an existing username)
25d.	Negative testing with invalid
26input (trying to add a username which is null)
27e.	Destructive testing 
28(sending null, empty string, integer
29or other types, odd date format, deleting necessary parameters)
30f.	Security, authorization, and
31permission tests (sending valid or 
32invalid access tokens to permitted or unpermitted endpoints)
333. Executing test cases
34For each API request I need to verify some items like:
35a.	Data accuracy: Check the request and
36response body whether those are as
37written on API documentation in terms
38of data type and data structure.
39b.	HTTP status code: For example,
40creating a resource should return 201
41CREATED and unpermitted requests 
42should return 403 FORBIDDEN, etc.
43c.	Response headers: HTTP server 
44headers have implications on both 
45security and performance.
46d.	Response body: Check valid JSON
47body and correct field names, types
48, and values - including in error responses.
49e.	Authorization checks: Check authentication
50and authorization
51f.	Error messages: Check the error code 
52coverage in case API returns any error
53g.	Response time: Implementation of response timeout
544. Test flows
55We need to implement the next test flow
56if previous flow is success:
57a.	Single-step workflow: Executing a 
58single API request and checking the
59response accordingly. Such basic tests
60are the minimal building blocks
61we should start with, and there’s no
62reason to continue testing if these tests fail.
63b.	Multi-step workflow with 
64several requests: For example, 
65we execute a POST request that creates
66a resource with id and we then use this
67id to check if this resource is present
68in the list of elements received by a GET request.
69Then we use a PATCH endpoint to update
70new data, and we again invoke a GET request
71to validate the new data. Finally, 
72we DELETE that resource and use GET
73again to verify it no longer exists.
74c.	Combined API and UI test:
75This is mostly relevant to manual testing, 
76where we want to ensure data integrity
77between the UI and API. We execute requests
78via the API and verify the actions through
79the UI or vice versa. The purpose of these
80integrity test flows is to ensure that although
81the resources are affected via different 
82mechanisms the system still maintains expected 
83integrity and consistent flow.    
84