Regarding security controls, there are several levels of abstraction within API security: controls within the business logic (protections against abuse stories), controls protecting the business logic (authentication and authorization), and finally architecture security controls that are enabled or defined by the architecture (API gateways, microsegmentation).
Security controls enabled by architectural decisions are relatively new to application development in the context of API security. Outside of security controls applied to business logic, these extend to concerns such as velocity checking, authentication, and authorization decisions. We are also left to wonder about how best to isolate a cluster of APIs, where important security controls can be enabled by a gateway. For example, does microsegmentation make the cut? How effective are service mesh provided controls?
Some architectural decisions seek to provide chokepoints, which allow security architects greater insight into these distributed systems. While some architectural decisions demand a centrally managed approach, others enable an endpoint-enforced approach. Others are a free-for-all. Leaders must also contend with and consider the claims from vendors entering the market with new application firewalls and data loss prevention (DLP) mechanisms.
We recommend threat modeling, of course. Application security leaders must begin the process of identifying the risks to various types of API (first party, third party, client, or consumer), key controls for each API endpoint, acceptable solutions for problems posed by API-heavy architectures (like microservices), and whether to buy into vendor claims as part of a risk management program.