Différence entre SPI et API?

À partir de Java effectif, 2e édition :

Un cadre de fournisseur de services est un système dans lequel plusieurs services les fournisseurs mettent en œuvre un service, et le système fait les implémentations disponible pour ses clients, découplage de la mise en œuvre.

Il y a trois composantes essentielles d'un cadre de fournisseur de services: a interface de service, quels fournisseurs mettre en œuvre; un enregistrement de fournisseur API, que le système utilise pour s'enregistrer implémentations, donnant accès aux clients pour eux; et une API d'accès au service, quels clients utilisent pour obtenir un instance du service. Service l'API access le permet généralement mais le fait ne pas exiger que le client en spécifie certains critères de choix d'un fournisseur. Dans l'absence d'une telle spécification, l'API renvoie une instance d'un défaut de mise en œuvre. Service l'API access est la " statique flexible usine " qui constitue la base de la cadre des fournisseurs de services.

Une quatrième composante facultative d'un le cadre de fournisseur de services est un interface de fournisseur de services, qui les fournisseurs mettent en œuvre pour créer instances de leur service application. En l'absence d'un interface fournisseur de services, les implémentations sont enregistrées par nom de classe et instancié reflectively (Point 53). Dans le cas de JDBC, la connexion joue le rôle du interface de service, DriverManager.registerDriver est le API d'enregistrement des fournisseurs, DriverManager.getConnection est le API d'accès au service, et le pilote est le interface fournisseur de services.

Il existe de nombreuses variantes de la modèle de cadre de fournisseur de services. Par exemple, l'API d'accès au service peut renvoyer une interface de service plus riche que celle du fournisseur, utilisation du modèle d'adaptateur [Gamma95, p. 139]. Voici une implémentation simple avec une interface de fournisseur de services et un fournisseur par défaut:

// 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 différence entre API et SPI vient lorsqu'une API fournit en outre des implémentations concrètes. Dans ce cas, le fournisseur de services doit implémenter quelques API (appelées SPI)

Un exemple est JNDI:

JNDI fournit des interfaces et des classes pour la recherche de contexte. La méthode par défaut pour rechercher un contexte est fournie dans IntialContext. Cette classe utilisera en interne des interfaces SPI (en utilisant NamingManager) pour les implémentations spécifiques au fournisseur.

Voir le JNDI Architecture ci-dessous pour une meilleure compréhension.

API signifie Interface de programmation d'application, où l'API est un moyen d'accéder à un service / fonction fourni par une sorte de logiciel ou une plate-forme.

SPI signifie Interface de fournisseur de services, où SPI est un moyen d'injecter, d'étendre ou de modifier le comportement d'un logiciel ou d'une plate-forme.

L'API est normalement cible pour les clients d'accéder à un service et il a les propriétés suivantes:

> > API est un moyen programmatique d'accéder à un service pour atteindre un certain comportement ou sortie

> > Du point de vue de l'évolution de l'API, l'ajout ne pose aucun problème pour les clients

- > Mais les API une fois utilisées par les clients, elles ne peuvent pas (et ne doivent pas) être modifiées / supprimées à moins qu'il n'y ait une communication appropriée, puisque c'est une dégradation complète de la attente du client

SPI d'autre part sont ciblés pour les fournisseurs et a les propriétés suivantes:

> > SPI est un moyen d'étendre / modifier le le comportement d'un logiciel ou d'une plate-forme (programmable vs programmatique)

- >SPI evolution est différent de l'évolution de l'API, dans la suppression de SPI n'est pas un problème

- >L'ajout d'interfaces SPI causera des problèmes et pourrait casser les implémentations existantes

Pour plus d'explications, cliquez ici : Interface du Fournisseur de Services

FAQ de NetBeans: Qu'est-ce qu'un SPI? Comment est-il différent à partir d'une API?

API est un terme général - un acronyme pour Application Programming Interface - cela signifie quelque chose (en Java, généralement certaines classes Java) qu'un logiciel expose, ce qui permet à d'autres logiciels de communiquer avec lui.

SPI signifie Interface Fournisseur de services. C'est un sous-ensemble de toutes les choses qui peuvent être spécifiques à l'API dans les situations où une bibliothèque fournit des classes appelées par le application (ou bibliothèque API), et qui changent généralement les choses que l'application est capable de faire.

L'exemple classique est JavaMail. Son API a deux côtés:

• Le côté API - que vous appelez si vous écrivez un client de messagerie ou si vous souhaitez lire une boîte aux lettres
• Le côté SPI si vous fournissez un gestionnaire de protocole filaire pour permettre à JavaMail de parler à un nouveau type de serveur, tel qu'un serveur news ou IMAP

Les utilisateurs de l'API ont rarement besoin de voir ou parlez aux classes SPI, et vice-versa.

Dans NetBeans, lorsque vous voyez le terme SPI, il s'agit généralement de classes qu'un module peut injecter à l'exécution qui permettent à NetBeans de faire de nouvelles choses. Par exemple, il existe un SPI général pour la mise en œuvre de systèmes de contrôle de version. Différents modules fournissent des implémentations de ce SPI pour CVS, Subversion, Mercurial et d'autres systèmes de contrôle de révision. Cependant, le code qui traite des fichiers (côté API) n'a pas besoin de se soucier s'il existe un système de contrôle de version, ou ce que c'est.

Je suppose qu'un SPI s'insère dans un système plus grand en implémentant certaines fonctionnalités d'une API, puis en s'enregistrant comme étant disponible via des mécanismes de recherche de service. Une API est utilisée directement par le code d'application de l'utilisateur final, mais peut intégrer des composants SPI. C'est la différence entre l'encapsulation et l'utilisation directe.

Interface de fournisseur de services est l'interface de service que tous les fournisseurs doivent implémenter. Si aucune des implémentations de fournisseur existantes ne fonctionne pour vous, vous devez écrire votre propre fournisseur de services (implémentant l'interface de service) et vous inscrire quelque part (voir le message utile de Roman).

Si vous réutilisez l'implémentation fournisseur existante de l'interface de service, vous utilisez essentiellement l'API de ce fournisseur particulier, qui inclut toutes les méthodes de l'interface de service plus quelques méthodes publiques de son propre. Si vous utilisez des méthodes d'API de fournisseur en dehors du SPI, vous utilisez des fonctionnalités spécifiques au fournisseur.

Dans le monde Java, différentes technologies sont censées être modulaires et "enfichables" dans un serveur d'applications. Il y a alors une différence entre

• le serveur d'applications
  • [SPI]
• la technologie enfichable
  • [API]
• l'application de l'utilisateur final

Deux exemples de telles technologies sont JTA (le gestionnaire de transactions) et JCA (adaptateur pour JMS ou base de données). Mais il en existe d'autres.

Implémenteur de tels une technologie enfichable doit ensuite implémenter le SPI pour être enfichable dans l'application. serveur et fournir une API à utiliser par l'application de l'utilisateur final. Un exemple de JCA est l'interface ManagedConnection qui fait partie du SPI, et la connexion qui fait partie de l'API de l'utilisateur final.

Il y a un aspect qui ne semble pas être beaucoup mis en évidence mais qui est très important pour comprendre le raisonnement derrière l'existence de la scission API/SPI.

La division API / SPI n'est requise que lorsque la plate-forme est appelée à évoluer. Si vous écrivez une API et "sachez" qu'elle ne nécessitera aucune amélioration future, il n'y a aucune raison réelle de diviser votre code en deux parties (en plus de faire une conception d'objet propre).

, Mais ce n'est presque jamais le cas et les gens doivent avoir la liberté de faire évoluer l'API avec les exigences futures - de manière rétrocompatible.

Notez que tout ce qui précède suppose que vous construisez une plate-forme que d'autres personnes utilisent et/ou étendent et non votre propre API où vous avez tout le code client sous contrôle et pouvez donc refactoriser comme vous le souhaitez.

Permet de le montrer sur l'un des objets Java bien connus Collection et Collections.

API: Collections est un ensemble d'utilitaire de méthodes statiques. Souvent, les classes représentant un objet API sont définies comme final car elles garantissent (au moment de la compilation) qu'aucun client ne peut jamais "implémenter" cet objet et elles peuvent dépendre de "appeler" ses méthodes statiques, par exemple

Collections.emptySet();

Puisque tous les clients sont "appelant" mais pas "implémentant", les auteurs de JDK sont libres d'ajouter de nouvelles méthodes dans l'objet Collections dans la future version de JDK. Ils peuvent être sûrs qu'il ne peut casser aucun client, même s'il y en a probablement des millions d'usages.

SPI: Collection est une interface qui implique que n'importe qui peut implémenter sa propre version de celui-ci. Ainsi, les auteurs de JDK ne peuvent pas y ajouter de nouvelles méthodes car cela casserait tous les clients qui ont écrit leur propre implémentation Collection (*).

Typiquement, quand une méthode supplémentaire doit être ajoutée, une nouvelle interface, par exemple Collection2 qui étend la première doit être créée. Le client SPI peut alors décider de migrer vers le nouveau version de SPI et implémenter sa méthode supplémentaire ou s'il faut s'en tenir à l'ancienne.

Vous avez peut-être déjà vu le point. Si vous combinez les deux pièces en une seule classe, votre API est bloquée de tout ajout. C'est aussi la raison pour laquelle les bonnes API et frameworks Java n'exposent pas abstract class car ils bloqueraient leur évolution future en ce qui concerne la compatibilité descendante.

Si quelque chose n'est pas encore clair, je recommande de vérifier cette page qui explique ce qui précède plus en détail.

(*) Notez que cela n'est vrai que jusqu'à Java 1.8 qui introduit le concept de default méthodes définies dans une interface.