Interface design is an easy task, it is difficult events. Everyone design of the interface, everyone can design, but also the resulting interface a wide variety of ideas. Work for so many years, I am also very sentiment. Many people will say, how simple interface design, as long as the name is good, then through the FBI, on-line you can call on the line. Particularly non-Internet industry people, meaning there is no discrimination. Because too many inconsistencies in the Internet industry and traditional industry decided to produce this idea.
Interface is the minimum size of projects inside the unit, interface design requires a lot of attention to the point, consider the needs of all aspects of a lot of people do not pay attention, but the interface technology stack design also requires a lot of need, to be able to fully examine the breadth of human knowledge and technology depth. Here is a summary of some at work, hoping to exchange together with you to explore.
First, the interface version of
Production environment, if there is no version control changes will result in a call interfaces stakeholders frequent follow changes, assuming that the parties did not follow the changes, the system will error, which affects the user's experience and make it to operation of the entire system is disadvantageous, difficulty docking interfaces will continue to increase.
If you have a version of the interface can control the upgrade system to grasp the initiative in the relevant parties, so that when there is a new version of the program released the old version of the business logic will not be affected, the impact from the user's perception has also been relatively small , interested parties can also be according to their own conditions if you want to upgrade.
Second, the interface for application scenario
When the design of the interface, we also consider the interface is a front-end development for web or mobile app development, or server-side development. Different scenarios overall plan is different interfaces (e.g.: When we provide a web interface or APP distal end use, we can use the interface security verification jwt, oauth2.0 the like, if we provide interface to the backend when using the service, then I can use token mechanism).
Third, the process requesting unity and normative parameters
Normative parameter request means is, what kind of an interface to receive parameters manner. It is a unified way it is received using json or xml form way or form is received.
In the development of the interface should be unified in one place to receive parameters, calibration and other operations right. In order to ensure the integrity of the parameters, we can consider adding a signature verification process.
Fourth, the return data type, and code information returned normative tips
Data type returned to the client should be unified (for example: the reunification of our return, or return to unity in the form of xml, json in the form of).
Different design mode interface return code will be different, if the fire is now very popular restfull style then they should be allowed to return restfull style code provisions. If you are using unified custom return code, then return in the design code, you should have to learn different business processing module for processing the return code segment (for example: The system we use 10000-10050 basic management, user management, you should want 10051-10100, ......), for different business modules we have to set aside enough return code, because the latter for the development of the module may also have other business expansion or adjustment problems.
One advantage of the fragmentation process return code is conveniently call interface stakeholders can quickly locate the error is which part belongs to, but also to facilitate the interface developers to locate where in the interface error.
In addition to the return code, we return to the interface error messages and interface call success message should be clear, the point on the tips. Of course, some error messages may be factors such as bug or issue its own server API, so we should not be transformed what prompted the parties to the interface API calls exposed their own problems, this will lead to security issues such as the interface.
Fifth, the control interface secure authentication and rights
Each operator interface is not able to request access, so we need to interface provides a secure authentication, like user login system, there is no legitimate registered users of our system, we are not allowed to request access. So how do we verify the safety of the interface it? In fact, we are not the same secure authentication interface for different application scenarios (for example: when our interface is available to APP web front-end or end use, secure authentication interfaces we can use jwt, oauth2.0 etc. If our interface is providing back-end services to use, then I can use token mechanism).
Control authority means for different user groups, we have to assign different permissions (eg: Super administrator can operate all interfaces, common user interface to allow only part of the operation), where in addition to a user population that we can call for different interfaces interested parties (stakeholders here refers to the application call interface) to control permissions.
Sixth, call frequency interface control
On the call frequency interface control on the other hand also for the safety and maintainability of the interface to, of course, whether here or to be controlled depending on different scenarios for interface design, some of the interface interfaces visits do not need to restrict call frequency, and some interfaces are on the interface call is to be strictly controlled (for example: the development of micro-channel public number of well-known is to call frequency interface restrictions and limits for different scenarios and user groups the frequency is not the same).
Seven, request log record interface
We should do some logging of interface requests, so when we later maintenance interfaces will greatly reduce maintenance costs. But also for related statistical processing for logs.
Eight, the readability of the document Interface
Readability interface documentation is very important, not really developed an interface to complete, if people do not use your interface, then your interface developed is of no use, very many programmers do not pay attention and write interface documentation Interface document readability, written documentation like a bible looking at the big head. Good documentation should let people see that how to call, how to avoid some of the pit, plain and simple, and so on.