(1) Organizing the project requirements, writing API requirements documents , including API return results, query parameters and so on.
(2) Define the RESTful API interface.
(3) test the RESTful API interface.
(4) Write API documentation , including API name, path, HTTP method, request parameters, function template, return results, etc., to facilitate the use of the module developers and testers.
(5) Testers test API, mainly test system performance, there are some outstanding scene testing, such as multi-threading, concurrent operation. Writing API test reports
(6) API interface Invocation, project development phase.
Note: The above 5 and 6 can be done at the same time without affecting each other. The main production of three API documentation: requirements documentation, documentation, test documentation.
Here I summarize 2 and 3 to define and test some of the experience of restful APIs, there are questions or additions to the place please enlighten us!
One: Define restful APIs
(1) API path
Before the API was defined in the project, a very serious problem was made. There are a number of verbs in the API resource path that do not follow the restful specification.
In a restful architecture, each URL represents a resource (resource), so there can be no verbs in the URL, only nouns.
For example, the API to get a product can be defined like this
Get a single product: HTTP://127.0.01:8080/APPNAME/REST/PRODUCT/1
Get Multiple Products: http://127.0.01:8080/AppName/rest/products
(2) HTTP method
The usual HTTP verbs have the following four (the corresponding SQL command in parentheses).
GET (SELECT): Remove resources from the server (one or more items).
POST (Create): Creates a new resource on the server.
PUT (UPDATE): Updates the resource on the server (the client provides a full resource after the change).
Delete: Deletes a resource from the server.
RestFul API Definition Process Specification