Diferencia entre SPI y API?

From Effective Java, 2nd Edition :

Un marco de proveedores de servicios es un sistema en el que múltiples servicios los proveedores implementan un servicio, y el sistema hace las implementaciones a disposición de sus clientes, desacoplando de las implementaciones.

Hay tres componentes esenciales de un marco de proveedores de servicios: a interfaz de servicio, qué proveedores implementar; un registro de proveedor API, que el sistema utiliza para registrar implementaciones, dando acceso a los clientes a ellos; y una API de acceso al servicio, qué clientes utilizan para obtener un instancia del servicio. Servicio la API de acceso generalmente lo permite, pero lo hace no requiere que el cliente especifique algunos criterios para elegir un proveedor. En la ausencia de tal especificación, la API devuelve una instancia de un implementación predeterminada. Servicio access API es la " estática flexible fábrica " que forma la base de la marco del proveedor de servicios.

Un cuarto componente opcional de una el marco del proveedor de servicios es un interfaz del proveedor de servicios, que proveedores implementan para crear instancias de su servicio aplicación. En ausencia de un interfaz del proveedor de servicios, las implementaciones son registradas por nombre de clase e instancias reflexivamente (Tema 53). En el caso de JDBC, La conexión juega el papel de la interfaz de servicio, DriverManager.registerDriver es el API de registro de proveedores, DriverManager.getConnection es el service access API, y el controlador es el interfaz del proveedor de servicios.

Hay numerosas variantes de la patrón del marco del proveedor de servicios. Por ejemplo, la API de acceso al servicio puede devolver una interfaz de servicio más rica que el requerido del proveedor, usando el patrón del adaptador [Gamma95, p. 139]. Aquí está una implementación simple con una interfaz de proveedor de servicios y un proveedor predeterminado:

// Service provider framework sketch

// Service interface
public interface Service {
    ... // Service-specific methods go here
}

// Service provider interface
public interface Provider {
    Service newService();
}

// Noninstantiable class for service registration and access
public class Services {
    private Services() { }  // Prevents instantiation (Item 4)

    // Maps service names to services
    private static final Map<String, Provider> providers =
        new ConcurrentHashMap<String, Provider>();
    public static final String DEFAULT_PROVIDER_NAME = "<def>";

    // Provider registration API
    public static void registerDefaultProvider(Provider p) {
        registerProvider(DEFAULT_PROVIDER_NAME, p);
    }
    public static void registerProvider(String name, Provider p){
        providers.put(name, p);
    }

    // Service access API
    public static Service newInstance() {
        return newInstance(DEFAULT_PROVIDER_NAME);
    }
    public static Service newInstance(String name) {
        Provider p = providers.get(name);
        if (p == null)
            throw new IllegalArgumentException(
                "No provider registered with name: " + name);
        return p.newService();
    }
}

La diferencia entre API y SPI viene cuando una API proporciona adicionalmente algunas implementaciones concretas. En ese caso, el proveedor de servicios tiene que implementar algunas API (llamadas SPI)

Un ejemplo es JNDI:

JNDI proporciona interfaces y algunas clases para la búsqueda de contexto. La forma predeterminada de buscar un contexto se proporciona en IntialContext. Esta clase internamente usará interfaces SPI (usando NamingManager) para implementaciones específicas del proveedor.

Ver el JNDI Arquitectura a continuación para una mejor comprensión.

API significa Interfaz de programación de aplicaciones, donde API es un medio para acceder a un servicio / función proporcionada por algún tipo de software o una plataforma.

SPI significa Interfaz de proveedor de servicios, donde SPI es una forma de inyectar, extender o alterar el comportamiento del software o una plataforma.

La API es normalmente el objetivo para que los clientes accedan a un servicio y tiene las siguientes propiedades:

API > API es una forma programática de acceder a un servicio para lograr un cierto comportamiento o salida

From>Desde el punto de vista de la evolución de la API, la adición no es ningún problema para los clientes

But > Pero las API una vez utilizadas por los clientes no pueden (y no deben) ser alteradas / eliminadas a menos que haya una comunicación adecuada, ya que es una degradación completa de la expectativa del cliente

Por otra parte, los SPI están dirigidos a proveedores y tienen las siguientes propiedades:

SP > SPI es una forma de extender / alterar el el comportamiento de un software o plataforma (programable vs programática)

Evolution>La evolución de SPI es diferente de la evolución de API, en la eliminación de SPI no es un problema

Addition > La adición de interfaces SPI causará problemas y puede romper las implementaciones existentes

Para más explicación haga clic aquí: Interfaz del Proveedor de servicios

NetBeans ' FAQ: ¿Qué es un SPI? ¿En qué se diferencia de una API?

API es un término general, un acrónimo de Interfaz de programación de aplicaciones, que significa algo (en Java, generalmente algunas clases de Java) que expone una pieza de software, lo que permite que otro software se comunique con él.

SPI significa Interfaz del proveedor de servicios. Es un subconjunto de todas las cosas que pueden ser específicas de la API para situaciones en las que una biblioteca proporciona clases aplicación (o biblioteca API), y que normalmente cambian las cosas que la aplicación es capaz de hacer.

El ejemplo clásico es JavaMail. Su API tiene dos lados:

• El lado de la API, al que llama si está escribiendo un cliente de correo o desea leer un buzón
• El lado SPI si está proporcionando un controlador de protocolo de cable para permitir que JavaMail hable con un nuevo tipo de servidor, como un servidor de noticias o IMAP

Los usuarios de la API rara vez necesitan ver o hable con las clases de SPI, y viceversa.

En NetBeans, cuando ves el término SPI, generalmente está hablando de clases que un módulo puede inyectar en tiempo de ejecución que permiten a NetBeans hacer cosas nuevas. Por ejemplo, existe un SPI general para implementar sistemas de control de versiones. Diferentes módulos proporcionan implementaciones de ese SPI para CVS, Subversion, Mercurial y otros sistemas de control de revisiones. Sin embargo, el código que se ocupa de los archivos (el lado de la API) no necesita preocuparse si hay un sistema de control de versiones, o lo que es.

Supongo que un SPI se inserta en un sistema más grande mediante la implementación de ciertas características de una API, y luego se registra como disponible a través de mecanismos de búsqueda de servicios. El código de la aplicación del usuario final utiliza una API directamente, pero puede integrar componentes SPI. Es la diferencia entre encapsulación y uso directo.

La interfaz del proveedor de servicios es la interfaz de servicio que todos los proveedores deben implementar. Si ninguna de las implementaciones de proveedores existentes funciona para usted, debe escribir su propio proveedor de servicios (implementando la interfaz de servicio) y registrarse en algún lugar (consulte la publicación útil de Roman).

Si está reutilizando la implementación del proveedor existente de la interfaz de servicio, básicamente está utilizando la API de ese proveedor en particular, que incluye todos los métodos de la interfaz de servicio además de algunos métodos públicos propios. Si está utilizando métodos de la API del proveedor fuera de SPI, está utilizando características específicas del proveedor.

En el mundo Java, las diferentes tecnologías están destinadas a ser modulares y "conectables" a un servidor de aplicaciones. Hay entonces una diferencia entre

• el servidor de aplicaciones
  • [SPI]
• la tecnología enchufable
  • [API]
• la aplicación de usuario final

Dos ejemplos de tales tecnologías son JTA (el administrador de transacciones) y JCA (adaptador para JMS o base de datos). Pero hay otros.

Implementer of such una tecnología conectable debe implementar el SPI para que sea conectable en la aplicación. servidor y proporcionar una API para ser utilizada por la aplicación de usuario final. Un ejemplo de JCA es la interfaz ManagedConnection que es parte del SPI, y la conexión que es parte de la API de usuario final.

Hay un aspecto que no parece estar muy destacado, pero es muy importante para entender el razonamiento detrás de la existencia de la división API/SPI.

La división API / SPI solo es necesaria cuando se espera que la plataforma evolucione. Si escribe una API y "know" no requerirá ninguna mejora futura, no hay razones reales para dividir su código en las dos partes (además de hacer un diseño de objetos limpio).

Pero esto casi nunca es el caso y las personas necesitan tener la libertad de evolucionar la API junto con los requisitos futuros, de una manera compatible con versiones anteriores.

Tenga en cuenta que todo lo anterior asume que está construyendo una plataforma que otras personas usan y/o extienden y no su propia API donde tiene todo el código del cliente bajo control y, por lo tanto, puede refactorizar como lo necesite.

Vamos a mostrarlo en uno de los conocidos objetos Java Collection y Collections.

API: Collections es un conjunto de métodos estáticos de utilidad. A menudo las clases que representan el objeto API se definen como final ya que garantiza (en el momento de la compilación) que ningún cliente puede nunca "implementar" ese objeto y pueden depender de "llamar" sus métodos estáticos, por ejemplo,

Collections.emptySet();

Dado que todos los clientes están "llamando" pero no "implementando", los autores de JDK son libres de agregar nuevos métodos al objeto Collections en la futura versión de JDK. Pueden estar seguros de que no puede romper cualquier cliente, incluso si hay probablemente millones de usos.

SPI: Collection es una interfaz que implica que cualquiera puede implementar su propia versión de la misma. Por lo tanto, los autores de JDK no pueden agregar nuevos métodos en él ya que rompería todos los clientes que escribieron su propia implementación Collection (*).

Normalmente cuando se requiere agregar un método adicional, se debe crear una nueva interfaz, por ejemplo Collection2 que extienda la anterior. SPI cliente entonces puede decidir si migrar a la nueva versión de SPI e implementar su método adicional o si seguir con el anterior.

Puede que ya hayas visto el punto. Si combina ambas piezas en una sola clase, su API se bloquea de cualquier adición. Esa es también la razón por la que las buenas API y Frameworks de Java no exponen abstract class ya que bloquearían su evolución futura con respecto a la compatibilidad con versiones anteriores.

Si algo aún no está claro, recomiendo revisar esta página que explica lo anterior con más detalle.

(*) Tenga en cuenta que esto es cierto solo hasta Java 1.8 que introduce el concepto de default métodos definidos en una interfaz.