Openapi interface design ideas

    Open API is an open API, also known as an open platform. The so-called Open API (OpenAPI) is a common application of service-oriented websites. The service provider of the website encapsulates its own website service into a series of API (Application Programming Interface, application programming interface) and opens it up for use by third-party developers. This behavior is called the API of the open website, and the open API is called OpenAPI (Open API).

    In the past, software development was designed for specific users or groups, but the needs of users are very different. With the development of software development, people's concerns and design patterns are also quietly changing. Instead of developing for specific customers, I should design from the perspective of the public and release myself from the curse of Party A and Party B. , Become a party yourself. That is to say, the software I developed in the past is only for you, and you are not satisfied. Now I only provide the core business, you can connect it yourself, and you can design it as you want. So Opean Api came into being! ! Taobao, Ali, and Tencent all do this. They are big companies, and they set the rules. How they define the interface, you have to connect! ! There is a website called Aggregate Data, which provides some free and premium APIs. Those who are interested can register and play.

    Regarding how to develop such a set of interfaces, let's not talk about the actual business logic, let's see how to design it? The following are my thoughts on the problems encountered during the design, which may not be comprehensive for reference only!

Let's take a look at what points need to be considered? I also rely on experience and Google.

1. Signature authentication (I need to know who is requesting me and whether I have permission to access this interface)
2. Traffic control (I can't let you access me without restraint, I want to be able to shut you down at any time)
3. Request forwarding (requested url, you need to find the real business processing logic, api is best only responsible for the specification of the interface, not responsible for the implementation of the business)
4. Log processing (you can keep silent, but every word you say will become a testimonial)
5. Exception handling (even if there is something wrong with Lao Tzu, you will not see my exception stack information, I will tell you that I am sick, please try again later)
6. Parameter specification (those who follow me advocate, those who go against me die)
7. Multi-machine deployment (I have nine lives)
8. Asynchronous callback (don't try to block me, but I can kill you)
9. Error messages (you need to recognize your mistakes)

    The most important thing in making APIs, especially Open APIs, is security, safety, and security. Just imagine, I can guess the account password right on your interface, and I can DDOS you casually. You have no way to guarantee user information. Safety, who would dare to use you. In fact, you are doing an anti-hacker design, huh, isn't it a lot taller.

Client: How do you know a request is from me and not someone else?

API: If you connect with me, I will give you a unique name in the world. When you request, tell me your name is xxx, and assign it to the app_key in the request. As for whether this field is called app_key or UserName or client_id , this depends on your mood. So there is the first function of the interface, giving the client a unique name.

Client: What if someone else knows this username and impersonates me?

API: I will also give you a matching password. The password is only known to you and me. When you request, bring the password over. I will verify the password first, and then I will allow access to the password. That way no one can pretend to be you. If you lose your password, that's your business.

Client: Now HTTP is all plaintext communication. I bring my account and password with me every time I visit, doesn't that mean it is advertised in the world? It's like walking on the road with a bag of money and shouting "Come and grab me! Come and grab me!", a small sniffer can get the user's password, if the user is used to using one password everywhere, then you are in a big trouble, hackers can use the method of credential stuffing to get the user All the information in one pot.

API: Then use your account password to exchange for a password with me. We call it token, so we will recognize those who carry the password and the password is correct. Run around the world with a password.

Client: But what if the Token is intercepted? What to do with the hacker replay! !

API: This password has an expiration time, such as 10 minutes, one hour, one day, 3 months, etc. You can also achieve single sign-on, and I can also effectively control the intrusion of outsiders, while avoiding repetition Repeated querying of the database and comparison of information can definitely improve the response speed, and the time spent verifying the validity of the token is definitely faster than querying the database. When the server-side interface is called, we can compare the ip address, user-agent and other information that initiates the request to prevent forgery. Then, if the validity period of the token is set small, it will expire after a while, and unless the hacker can continue to intercept your token, he can only stare blankly.

Client: This is fine, but there is still a chance that it will be stolen when I enter the password for the first time?

API: Then use HTTPS, and the passwords are transmitted with the SSL encryption protocol. I think who can steal it? If you are still struggling, let's use asymmetric?

Client:…

API: Is there anything else to say? If you have nothing to say, just connect honestly

Network attack and defense

1. CORS
2. CSRF
3. Hijacking attack
4. DDOS
5. XSS
6. SQL injection
7. File upload vulnerability
8. buffer overflow