Différence entre SPI et API?

From Effective Java, 2nd Edition :

un cadre pour les fournisseurs de services est système dans lequel plusieurs services les fournisseurs mettent en œuvre un service, et système rend les implémentations disponible pour ses clients, decoupling de la mise en œuvre.

il y a trois composants essentiels d'un fournisseur de services framework: un interface de service, quels fournisseurs la mise en œuvre; un inscription des fournisseurs API, que le système utilise pour enregistrer implémentations, donnant accès aux clients à eux; et une API d'accès au service, dont les clients utilisent pour obtenir un instance du service. Service L'API d'accès permet généralement mais ne permet pas ne pas exiger que le client spécifie critères de choix d'un fournisseur. Dans l'absence d'une telle spécification, L'API renvoie une instance d'un mise en œuvre par défaut. Service l'API d'accès est le " flexible static usine" qui à la base de la fournisseur de services-cadre.

un quatrième élément facultatif d'un le cadre pour les fournisseurs de services est l'interface avec les fournisseurs de services, qui les fournisseurs mettent en œuvre pour créer exemples de leur service application. En l'absence d'un interface avec les fournisseurs de services, les implémentations sont enregistrés par nom de la classe et instancié réflectivement (point 53). Dans le cas de JDBC, Connection joue le rôle de interface de service, DriverManager.registerDriver est le API d'enregistrement des fournisseurs, DriverManager.getConnection est le service access API, et le pilote est le interface du fournisseur de services.

Il existe de nombreuses variantes de la fournisseur de services-cadre modèle. Par exemple, L'API d'accès au service peut retourner une interface de service plus riche que celle du fournisseur, en utilisant le modèle D'Adaptateur [Gamma95, p. 139]. Voici une mise en œuvre simple avec un service de interface fournisseur 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 quand une API fournit en plus quelques implémentations concrètes. Dans ce cas, le fournisseur de services doit mettre en œuvre quelques IPA (appelés IPS)

un exemple est JNDI:

JNDI fournit des interfaces et de classes pour le contexte de recherche. La façon par défaut de rechercher un contexte est fournie en Contexteintial. Cette classe utilise en interne les interfaces SPI (en utilisant NamingManager) pour les fournisseurs spécifiques application.

voir L'Architecture JNDI ci-dessous pour une meilleure compréhension.

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

SPI signifie Service Provider Interface, 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 destinée aux clients pour leur permettre d'accéder à un service et elle présente les caractéristiques suivantes: propriétés:

-->API est un moyen via un programme d'accès à un service pour atteindre un certain comportement ou de sortie

-- > du point de vue de L'évolution de L'API, l'ajout n'est pas un problème du tout pour les clients

-- > mais les API utilisées par les clients 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 sur l'autre partie sont ciblées pour les fournisseurs et présente les propriétés suivantes:

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

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

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

pour plus d'explications Cliquez ici : Service Provider Interface

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

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

SPI signifie Service Provider Interface. C'est un sous-ensemble de toutes les choses qui peuvent être spécifiques à L'API situations où une bibliothèque fournit des classes qui sont appelées par l'application (ou la bibliothèque API), et qui changent typiquement les choses que l'application est capable de faire.

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

• L'API secondaires que vous appelez si vous êtes à la rédaction d'un client de messagerie ou l'envie de lire un de boîte aux lettres
• le côté SPI si vous fournissez un gestionnaire de protocole pour permettre à JavaMail pour parler à un nouveau type de serveur, comme un serveur de nouvelles ou IMAP

les utilisateurs de L'API ont rarement besoin de voir ou de parler aux classes SPI, et vice-versa.

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

je suppose qu'un SPI s'introduit 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 encapsulation et usage direct.

Service provider interface est l'interface de service qui tous les fournisseurs doivent mettre en œuvre. Si aucune des implémentations de fournisseur existantes ne fonctionne pour vous, vous devez écrire votre propre fournisseur de services (implémenter l'interface de service) et vous inscrire quelque part (voir le post utile de Roman).

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

dans le monde Java, différentes technologies sont conçues pour être modulaires et" branchables " dans un serveur d'application. Il y a alors une différence entre

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

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

mise en œuvre d'une telle technologie Plug-inable doit alors mettre en œuvre le SPI pour être Plug-inable 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 de la SPI, et la Connection qui fait partie de l'API de l'utilisateur final.

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

API/SPI split est nécessaire uniquement lorsque la plateforme est appelé à évoluer. si vous écrivez une API et "savoir" il ne nécessitera aucune amélioration future jamais, il n'y a pas de vraies raisons de diviser votre code en deux parties (en plus de rendre l'objet propre conception.)

mais ce n'est presque jamais le cas et les gens ont besoin d'une liberté d'évoluer API avec les besoins futurs - d'une 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 remanier tout ce dont vous avez besoin.

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

API: Collections est un ensemble de méthodes d'utilité statique. 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 pourra jamais "implémenter cet objet et elles peuvent dépendre de "appeler ses méthodes statiques, par exemple

Collections.emptySet();

comme 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 pas briser n'importe quel client, même s'il y a probablement des milliers d'utilisations.

SPI: Collection est une interface qui implique que n'importe qui peut mettre en place son propre version de celui-ci. Ainsi, les auteurs de JDK ne peuvent pas y ajouter de nouvelles méthodes car cela briserait 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 l'ancienne doit être créée. Le client SPI peut alors décider s'il doit migrer vers la nouvelle version de SPI et mettre en œuvre sa méthode supplémentaire ou s'il doit coller avec l'ancienne.

vous pourriez déjà vu le point. Si vous combinez les deux pièces en une seule classe, votre API est bloquée. C'est aussi la raison pour laquelle les bons API et les cadres Java n'exposent pas abstract class car ils bloqueraient leur évolution future en ce qui concerne la rétrocompatibilité.

si quelque chose n'est pas encore clair, je vous recommande de vérifier cette page ce qui explique ci-dessus plus en détail.

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