An API is an application programming interface. It is a set of conventions: external programs initiate requests in the agreed manner, and the system returns results in the agreed format, without either side needing to understand how the other is implemented internally.
A helpful analogy
You can think of it as a waiter in a restaurant. You do not need to enter the kitchen; you simply order from the menu, the waiter passes the request to the kitchen, and then brings out the prepared dishes. The API plays exactly this role of transmission and convention—it defines "how to order, what can be ordered, and what it will look like when it comes back."
Common types of APIs
Network APIs. Based on common network protocols, they distinguish operation types through different request methods: read, create, update, and delete, each corresponding to one method. Data is mostly exchanged in a lightweight text format. This is currently the most common type, and it is what websites and mini programs mostly use when connecting to external services.
Query-style APIs. They allow the caller to specify which fields are needed and retrieve only the parts to be used, reducing unnecessary data round trips. When frontend display requirements change frequently, this approach is more flexible.
Library and function APIs. They provide ready-made capabilities in the form of code libraries that can be called directly in a program, saving the effort of reinventing the wheel.
System-level APIs. They provide operating-system-level capabilities such as file reading and writing and process management.
Remote procedure calls. They make it as easy to call functions on a remote server as to call local functions.
How APIs verify identity
There are three common methods: keys—each request carries a credential, and the service provider verifies its validity; authorization protocols—users authorize third parties to access their data without having to hand over passwords; tokens—a kind of credential with a validity period that can carry identity information, suitable for scenarios with frontend-backend separation. Which one to choose depends on the usage scenario and security requirements; the more open the API, the stricter the permission scope required.
Where enterprise websites use it
Connecting website and mini program business to avoid maintaining a separate set of data on each side; integrating external services such as payment, logistics, and SMS; synchronizing internal system data to public-facing pages, such as inventory, prices, and order status. The common point of these scenarios is that data appears only where it is needed, rather than being repeatedly moved manually.
A few reminders
APIs have the concept of versions, and upgrades must consider whether existing callers can remain compatible. API stability affects the entire business chain, so monitoring and fault-tolerance design are needed; you cannot assume the other party will always respond normally. When opening APIs externally, permissions should be granted on a least-privilege basis—the more permissions granted, the greater the loss when problems occur.