Understanding SPI vs API: When to Use Service Provider Interfaces versus Application Programming Interfaces

The article introduces the concept of distinguishing Service Provider Interfaces (SPI) from Application Programming Interfaces (API) and explains why this distinction matters in software architecture.

It first outlines three possible locations for an interface between a caller and an implementer: within the caller's package, within the implementer's package, or in an independent package.

For the case where the interface resides in the caller's package, the article uses a repository interface example in a Domain‑Driven Design (DDD) context, showing that the domain layer depends on the interface while the implementation lives elsewhere, preserving the benefits of interface‑oriented programming.

It then defines SPI as a service provider interface and lists its rules: conceptually dependent on the caller, organized in the caller’s package, implementation in a separate package, and typical use in plug‑in architectures.

Next, the article defines API, stating its rules: conceptually closer to the implementer, organized in the implementer’s package, and both interface and implementation co‑locate, with examples such as the IUnityContainer interface.

The article compares SPI and API across dimensions such as extensibility, interaction, dynamism, security, and versioning, and provides guidance on choosing between them based on these factors.

Finally, it emphasizes that architecture involves trade‑offs rather than a one‑size‑fits‑all solution.