Traditionally, developers built applications and then discovered that parts of the infrastructure necessary for their application might useful on their own, or that it would be beneficial for third-party developers to access the capabilities of their application programmatically and maybe even extend it. Later, with the proliferation of Web applications the Application programming interface (API) concept was used for exposing the capabilities of a Web site programmatically. Several flavors of Web APIs became popular, first the XML-based SOAP APIs and then REST APIs. Most recently, the JSON-based GraphQL is all the rage.
Benefits of Providing an API
Providing an API is useful because it cleanly separates the user interface from the core functionality of the system. Many types of user interfaces may employ the same API (if it's designed properly). These days, some companies and business models provide just an API and let the users (who are developers) build their own user interfaces. This approach allows you to really focus all your resources on the secret sauce and not worry about visual user interface. Of course API design becomes critical and user experience with the API is key to its success.
Another huge benefit is the indirection afforded by a well-designed API. As David Wheeler once said, introducing another layer of indirection solves all problems in computer science... Except for the problem of too many layers of indirection.
Let's consider the following example. You came up with this amazing idea for a startup — you'll develop a To-do application. People will be able to add tasks and mark them as done. You decide to store the users, the tasks and their status in a database. As an insightful developer you see the benefit of providing developers a programmatic access to your To-do management system. You decide to publish the URL of your database and let developers connect to it.
Direct Database Access: Boom! you just got owned. OK. You decide to limit access with developer accounts. You're still in deep trouble. If your system has broad appeal and everybody wants access, you'll have to grant a lot of developer accounts. How would you vet them? How do you revoke their privileges when they abuse your trust? Welcome to DOS and DDOS land.
Frozen Schema: You can't change your schema anymore, because third-party party developers rely on it.
Versioning: You can't version your application because people rely on the way it works right now and there is no good way to run old and new side by side.
Performance: All these developers connecting directly to your database and running huge queries are causing denial of service, intentionally or not. You can't shard your database without breaking your user's code. If you require them to work with a sharded database, then they'll have to implement complicated and fragile connection logic on their end. This can be mitigated by providing client libraries in all the popular languages. But, you've just took on a huge development and maintenance burden for all those client libraries.
APIs to the Rescue
APIs address all of these problems elegantly. The API sits in front of your database. It provides a familiar face to developers. You can secure the API using industry best practices. You can load balance the API. You can add caching easily. You can version the API and control deprecation of old APIs. What happens behind the API, stays behind the API. You can now take your SQL database and migrate it to a different database. Schema changes are invisible. You can throttle access at the API level and offload the burden of user management at the database level. If you use stateless request-response REST APIs (or even GraphQL) then connectivity becomes a non-issue. You only need to maintain your API. If your service is successful then a community will arise and other people will develop client libraries for your API in various programming languages.
APIs support many best practices such as separation of concerns, information hiding and layered architecture. They are a necessary and important aspect of any system that require programmatic access by users/developers. Pay attention to your APIs. Design them cleverly and curate and evolve them carefully.