Some suggestions for interface design

1. Parameter checking

The validity verification of parameters should be necessary for every interface , Whether it is a request initiated by the front end , Or other calls at the back end must verify the parameters , such as ： Length of parameter 、 type 、 Format , Whether the required parameters are transmitted , Whether it conforms to the agreed business rules, etc .

Recommended SpringBoot Validation To quickly realize some basic parameter verification .

Refer to the following example ：

@Data
@ToString
public class DemoEntity {
    
	
	//  Can't be empty , Spaces are removed during comparison 
    @NotBlank(message = " Name cannot be empty ")
    private String name;
	
	// amount Must be a greater than or equal to 5, Less than or equal to 10 The number of 
    @DecimalMax(value = "10")
    @DecimalMin(value = "5")
    private BigDecimal amount;

	//  Must conform to email Format 
    @Email
    private String email;
	
	// size The length must be in 5 To 10 Between 
    @Size(max = 10, min = 5)
    private String size;
	
	// age The size has to be in 18 To 35 Between 
    @Min(value = 18)
    @Max(value = 35)
    private int age;
	
	// user Not for null
    @NotNull
    private User user;
	
	//  Limit must be decimal , And integer digit integer most 2 position , Decimal places fraction At most 4 position 
    @Digits(integer = 2, fraction = 4)
    private BigDecimal digits;
	
	//  The limit must be a future date 
    @Future
    private Date future;

	//  The limit must be the expiration date 
    @Past
    private Date past;
	
	//  The limit must be a future or present time 
    @FutureOrPresent
    private Date futureOrPast;
	
	//  regular expression 
	@Pattern(regexp = "^\\d+$")
	private String digit;
}

@RestController
@Slf4j
@RequestMapping("/valid")
public class TestValidController {
    

    @RequestMapping("/demo1")
    public String demo12(@Validated @RequestBody DemoEntity demoEntity) {
    
        try {
    
            return "SUCCESS";
        } catch (Exception e) {
    
            log.error(e.getMessage(), e);
            return "FAIL";
        }
    }
}

2. Interface current limiting

When designing interfaces , We should evaluate the load capacity of the interface , Especially when it is provided to third parties , In this way, when the actual request traffic exceeds the expected traffic , We can take corresponding preventive strategies , Lest the server crash .

Generally speaking, current limiting is mainly to prevent malicious Dos Attack or crawler and other abnormal business access , Therefore, generally speaking, the method adopted is to directly discard the parts that exceed the threshold .

There are many specific implementations of current limiting , Stand alone version can use Guava Of RateLimiter, Distributed can use Redis+Lua, If you want a more complete set of solutions, you can use Alibaba open source sentinel.

3. Interface degradation 、 Fuse 、 Isolation

In this era of micro Services , A background request may go through several times RPC Invoked procedure , Therefore, the normal communication between services is very important , We cannot just because a service is unavailable , As a result, the nodes on the whole link are affected , Slowly, the whole service is unavailable , This is what we call avalanche effect .

If at this time B Service failure , Lead to A Service to B All requests for services were not responded in time , Then the final result is A All connections to the service are exhausted .

Need to know , In fact, there must be a network between our services , Of course, we will have other links to A Service request .

Such as the C Direct request A Of , Yes D request C, then C The request again A Of , Yes E Direct request A Of , So once A The connection of is exhausted , That means C/D/E Your connection will also be exhausted , Just roll more and more , Eventually, the node connection resources in the whole mesh are exhausted .

It can be seen that , The impact of the service avalanche problem is very serious , We must take precautions , And fusing 、 Demotion is a very effective way .

First, we need to fail quickly , Once the request response exceeds a certain time , It will automatically return to , Prompt the client for request timeout or something else , All in all , We need to respond quickly within the acceptable scope of the service .

Fusing can help us respond to requests that time out many times , Give some solutions , For example, no more requests within a certain time range , besides , It can also achieve resource isolation , For example, for X Interface call , Just allocate M A resource （ Resources here generally refer to threads ）.

And degradation can be understood as Plan B, That is, when the request response exceeds the threshold you set , What is your backup plan , What will happen next ？ Usually, the simpler way is to give a friendly response to the client , For example, the service is deserted , On the premise of ensuring the stability of the service , It can also give the client a good experience .

among netlfix Open source hystrix Components , Can be relaxed with spring cloud Ecological integration , It is for resource isolation 、 Service failure 、 There are mature solutions for degradation and so on , You can try to use .

4. Time out to try again

Use the retry mechanism , Believe that the request can still succeed , In some cases, the failure of a request may simply be caused by network instability , Maybe just ask again , At this time, it is not the best choice to return to the client directly if it fails .

There are also many retry strategies , For example, the number of retries 、 frequency , When the target node is a cluster deployment , You can also switch nodes and retry , such as ： If you ask for A Node failure , Then automatically switch to request B node .

Timeout retry can be used spring-retry, This is a spring Packaged API, Various retry strategies can be set directly through annotation , Implement retry mechanism .

netifix Open source ribbon, Load balancing as a client , It also encapsulates the retry mechanism , The bottom layer is also based on spring-retry Realized .

5. Idempotency

Since there are retries, we must consider idempotency , Idempotence , Simply speaking , It is to execute multiple repeated requests for an interface , The result is the same as that of a request , The concept sounds very easy to understand , But to really keep this goal in the system , It needs very rigorous design .

Except to try again 、 Like notification based on asynchronous callback 、MQ And other aspects of the design also determines that the interface must ensure idempotency , Of course, it does not mean that idempotency need not be considered as long as there is no such design , When talking about retry, I mentioned , The network itself also has a retry mechanism , We know TCP It's a reliable transport layer protocol , Since it is necessary to ensure that data packets can arrive , Then there must be a retry mechanism .

There are also many ways to ensure idempotency , such as ： Lock 、 Database unique key 、 State machine, etc .

6. Interface performance

Performance is a very broad topic , This article cannot be fully expanded , But it can provide some directions , Then readers can ponder and study along each direction .

6.1 parallel

Parallelism is to make full use of CPU A way of using resources ,JDK There are also many parallel tool classes , such as ：CompletableFuture, If there are multiple times in a request link IO request , And these requests have no sequential dependency , Then you can try parallel processing .

Parallelism requires us to control the problem of parallelism .

6.2 asynchronous

I believe in asynchronous 、 Concepts such as responsive programming must also be familiar , Asynchronism can easily achieve throughput far beyond synchronous requests , There are many business scenarios that are particularly suitable for asynchronous processing , For example, SMS notification after new user registration 、 Mail notification .

6.3 cache

When it comes to performance improvement , That must be the use of cache , This itself is determined by the design of the computer .

If you know about access delays at all levels , You can take targeted measures , For example CPU cache , Is the operating system level cache , Generally, what we can control is the type of access , Whether the data we need is obtained from disk or memory , Or through one TCP The request for .

Of course , Cache is good , But you can't use it indiscriminately , After all, resources are limited , Memory is much more expensive than disk , There is also the locality principle of space and time , You should also know everything , If the hit rate of cache is not high , Then it will backfire in the end .

6.4 Algorithm

We say we get the same result , The implementation process can be different ,O(n^2) Time complexity and O(n) Even O(logn) The time complexity gap is still obvious , This cannot be perceived when the amount of data is small , However, once there is a large amount of data , It's very obvious .

besides , The use of space must also be considered , Otherwise, frequent GC, As a result CPU Consumption is too high , Even the final internal deficiencies , Lead to OOM

7. Security

Last , There is another topic that cannot be bypassed , Interface security , If your interface is only used in the internal network , Then don't worry too much , But if it is an interface exposed in the public network environment , Then we must consider safety issues .

Interface security needs to be considered in many places , Still the same , This article can only mention a few , There is no way to expand one by one .

7.1 sensitive data

Sensitive information generally includes , Id card 、 cell-phone number 、 Bank card number 、 license plate number 、 Names, etc , It should be handled according to the desensitization rules .

7.2 Loophole attack

Generally including ,CSRF、XSS、SQL Inject 、 File upload vulnerability, etc .

CSRF

Cross-site request forgery （ English ：Cross-site request forgery）, Also known as one-click attack perhaps session riding, Commonly abbreviated as CSRF perhaps XSRF, It is a kind of coercion that users are currently logged in Web An attack method that performs unintended operations on an application . With cross site scripting （XSS） comparison ,XSS Using the user's trust in the designated website ,CSRF Using the trust of the website to the user's web browser .

XSS

Cross-site scripting attacks (Cross Site Scripting, XSS) Occurs on the client side , Can be used to steal privacy 、 A fishing scam 、 Steal the code 、 Spreading malicious code and other attacks . Malicious attackers put the code harmful to the client on the server as a web page content , Make other website users watch this page , This code is injected into the user's browser and executed , Make users vulnerable . generally speaking , Use cross site scripting to attack , An attacker can steal a session Cookie So as to steal the privacy of website users .

SQL Inject

SQL Injection means web The application does not judge or filter the validity of the user's input data , Attackers can web Add extra... At the end of a predefined query statement in the application SQL sentence , Implement illegal operation without the administrator's knowledge , In this way, the database server is cheated to execute any unauthorized query , So we can get the corresponding data information .

File upload vulnerability

Web When the application handles file downloading , Accept the path and file name specified by the user to download , An attacker can use this vulnerability to download other files or even arbitrary files of the server （ Source code 、 The database even passwd etc. ）.

7.3 Token、 encryption 、 Signature

Token The mechanism is mainly used for identity authentication , In the interface provided externally , Used to identify the identity of the interface requestor .

Signatures can be used to prevent data tampering 、 Encryption can be used to prevent data from being peeped .

7.4 black 、 White list mechanism

Using the whitelist mechanism can further strengthen the security of the interface , Once the service interacts with the service, you can use , The interface provider can limit only those in the whitelist IP Ability to visit , In this way, the interface requester just exports it IP Just provide it .

The corresponding blacklist mechanism , It is the interaction between the server and the client , Because of the client side IP It's not fixed , So you can't use the whitelist mechanism , However, we can still use the blacklist to intercept some requests that have been identified as illegal IP.