Różnica między SPI a API?

From Effective Java, 2nd Edition :

Framework usługodawcy jest system, w którym wiele usług usługodawcy realizują usługę, a system sprawia, że wdrożenia dostępne dla swoich klientów, ich z implementacji.

Istnieją trzy podstawowe składniki z RAM usługodawcy: a Interfejs serwisowy, który dostawcy wdrożenie; Rejestracja dostawcy API, którego system używa do rejestracji wdrożenia, dając klientom dostęp do nich; oraz API dostępu do usługi, które klienci wykorzystują do uzyskania przykład usługi. Serwis access API zazwyczaj pozwala, ale robi nie wymagają od klienta określenia niektórych kryteria wyboru dostawcy. W brak takiej specyfikacji, API zwraca instancję Domyślna implementacja. Serwis access API to " elastyczny statyczny fabryka", która stanowi podstawę struktura usługodawcy.

Opcjonalny czwarty składnik a Service provider framework to interfejs usługodawcy, który dostawcy wdrażają do tworzenia przykłady ich obsługi wdrożenie. W przypadku braku interfejs usługodawcy, wdrożenia są rejestrowane przez nazwa klasy i instancja refleksyjnie (poz. 53). W przypadku JDBC, Connection odgrywa rolę Interfejs serwisowy, DriverManager.registerDriver jest API rejestracji dostawcy, DriverManager.getConnection to API dostępu do usług, a Sterownik jest interfejs dostawcy usług.

Istnieje wiele wariantów wzór ramowy dostawcy usług. Na przykład interfejs API dostępu do usługi może zwrócić bogatszy interfejs usługi niż wymagane od dostawcy, za pomocą wzoru adaptera [Gamma95, s. 139]. Oto prosta realizacja z interfejsem usługodawcy i domyślny dostawca:

// 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();
    }
}

Różnica między API i SPI pojawia się, gdy API dodatkowo zapewnia pewne konkretne implementacje. W takim przypadku usługodawca musi zaimplementować kilka interfejsów API (zwanych SPI)

Przykładem jest JNDI:

JNDI dostarcza interfejsy i niektóre klasy do wyszukiwania kontekstu. Domyślnym sposobem wyszukiwania kontekstu jest IntialContext. Ta klasa wewnętrznie będzie używać interfejsów SPI (używając Namingmanagera) dla implementacji specyficznych dla dostawcy.

API oznacza Application Programming Interface, gdzie API jest środkiem dostępu do usługi / funkcji dostarczanej przez jakieś oprogramowanie lub platformę.

SPI oznacza Service Provider Interface, gdzie SPI jest sposobem na wstrzyknięcie, rozszerzenie lub zmianę zachowania oprogramowania lub platformy.

API jest zwykle celem dla klientów, aby uzyskać dostęp do usługi i ma następujące właściwości:

-- > API jest programowym sposobem dostępu do usługi aby osiągnąć określone zachowanie lub wyjście

-->z punktu widzenia ewolucji API, dodanie nie stanowi żadnego problemu dla klientów

-- > ale API jest kiedyś używane przez klientów nie może (i nie powinno) być zmieniane / usuwane chyba, że istnieją odpowiednie komunikaty, ponieważ jego całkowita degradacja oczekiwanie klienta

SPI z drugiej strony są przeznaczone dla dostawców i mają następujące właściwości:

-- > SPI to sposób na rozszerzenie / zmianę zachowanie oprogramowania lub platformy (programowalne vs. programmatic)

-- > ewolucja SPI różni się od Ewolucji API, w usuwaniu SPI nie jest problemem

-->dodanie interfejsów SPI spowoduje problemy i może uszkodzić istniejące implementacje

Aby uzyskać więcej wyjaśnień kliknij tutaj : interfejs dostawcy usług

FAQ NetBeans: Co to jest SPI? Czym różni się od API?

API jest ogólnym terminem - akronimem dla Application Programming Interface-oznacza coś (w Javie, zazwyczaj niektóre klasy Javy), co pozwala innym programom komunikować się z nim.

SPI oznacza Service Provider Interface. Jest podzbiorem wszystkich rzeczy, które mogą być API specyficzne dla sytuacji, w których biblioteka udostępnia klasy, które są wywoływane przez aplikacji (lub biblioteki API), które zazwyczaj zmieniają rzeczy, które aplikacja jest w stanie zrobić.

Klasycznym przykładem jest JavaMail. Jego API ma dwie strony:

• strona API - którą wywołujesz, jeśli piszesz klienta pocztowego lub chcesz odczytać skrzynkę pocztową
Po stronie SPI, jeśli udostępniasz obsługę protokołu przewodowego, aby JavaMail mógł rozmawiać z nowym rodzajem serwera, takim jak serwer wiadomości lub IMAP.]}

Użytkownicy API rzadko muszą zobaczyć lub porozmawiaj z klasami SPI i vice-versa.

W NetBeans, kiedy widzisz termin SPI, zwykle mówi on o klasach, które moduł może wstrzyknąć w czasie wykonywania, które pozwalają NetBeans robić nowe rzeczy. Na przykład istnieje ogólny SPI do wdrażania systemów kontroli wersji. Różne moduły zapewniają implementacje tego SPI dla CVs, Subversion, Mercurial i innych systemów kontroli wersji. Jednak kod, który zajmuje się plikami (po stronie API) nie musi dbać o to, czy istnieje system kontroli wersji, czyli co to jest.

Przypuszczam, że SPI łączy się z większym systemem poprzez implementację pewnych funkcji API, a następnie zarejestrowanie się jako dostępne za pośrednictwem mechanizmów wyszukiwania usług. Interfejs API jest używany bezpośrednio przez kod aplikacji użytkownika końcowego, ale może integrować komponenty SPI. To różnica między hermetyzacją a bezpośrednim użyciem.

Service provider interface to interfejs usługi, który wszyscy dostawcy muszą zaimplementować. Jeśli żadna z istniejących implementacji dostawcy nie działa dla ciebie, musisz napisać własnego Usługodawcę (implementującego interfejs usługi) i zarejestrować się gdzieś (zobacz przydatny post Romana).

Jeśli ponownie używasz istniejącej implementacji interfejsu usługi dostawcy, zasadniczo używasz API tego konkretnego dostawcy, które zawiera wszystkie metody interfejsu usługi plus kilka własnych metod publicznych. Jeśli używasz metod API dostawcy poza OIP, używasz funkcji określonych przez dostawcę.

W świecie Javy różne technologie mają być modułowe i "podłączane" do serwera aplikacji. Istnieje wtedy różnica między

• serwer aplikacji
  • [SPI]
[3]}technologia pluggable
• [API]
• aplikacja użytkownika końcowego

Wykonawca takich technologia pluggable musi następnie wdrożyć SPI, aby można było podłączyć w aplikacji. serwera i dostarczyć API do wykorzystania przez aplikację użytkownika końcowego. Przykładem JCA jest interfejs ManagedConnection, który jest częścią SPI, oraz połączenie , które jest częścią API użytkownika końcowego.

Jest jeden aspekt, który nie wydaje się być podkreślony zbytnio, ale jest bardzo ważny, aby zrozumieć uzasadnienie istnienia podziału API/SPI.

Podział API/SPI jest wymagany tylko wtedy, gdy platforma ma się rozwijać. jeśli napiszesz API i "wiesz" nie będzie to wymagało żadnych przyszłych ulepszeń, nie ma prawdziwych powodów do dzielenia kodu na dwie części (oprócz tworzenia czystych obiektów).

Ale tak prawie nigdy nie jest i ludzie muszą mieć swobodę rozwoju API wraz z przyszłymi wymaganiami - w sposób wstecznie zgodny.

zauważ, że wszystkie powyższe założenia zakładają, że budujesz platformę, z której korzystają i/lub rozszerzają inni ludzie, a nie własne API, w którym masz cały kod klienta pod kontrolą i dzięki temu możesz refaktorować w dowolny sposób.

Pokażmy go na jednym ze znanych obiektów Java Collection i Collections.

API: Collections jest zbiorem statycznych metod użytkowych. Często klasy reprezentujące obiekt API są definiowane jako final, ponieważ zapewnia to (w czasie kompilacji), że żaden klient nie może kiedykolwiek "zaimplementować" tego obiektu i mogą zależeć od "wywołania" jego statycznych metod, np.]}

Collections.emptySet();

Ponieważ wszystkie klienty są "wywołujące", ale nie "implementujące", autorzy JDK mogą swobodnie dodawać nowe metody do obiektu Collections w przyszłej wersji JDK. Mogą być pewni, że nie złamie żadnego klienta, nawet jeśli są prawdopodobnie miliony zwyczaje.

SPI: Collection jest interfejsem, który oznacza, że każdy może zaimplementować własną wersję. Dlatego autorzy JDK nie mogą dodawać do niego nowych metod , ponieważ złamałoby to wszystkich klientów, którzy napisali własną implementację Collection (*).

Zazwyczaj, gdy wymagane jest dodanie dodatkowej metody, należy utworzyć nowy interfejs, np. Collection2, który rozszerza poprzedni. Klient SPI może wtedy zdecydować, czy przenieść się do nowego wersja SPI i zaimplementować to dodatkowa metoda lub czy trzymać się starszej.

Może już widziałeś sens. Jeśli połączysz oba elementy w jedną klasę, Twoje API zostanie zablokowane przed dodatkami. Jest to również powód, dla którego dobre interfejsy API i frameworki Javy nie ujawniają abstract class, ponieważ blokowałyby ich przyszłą ewolucję w odniesieniu do kompatybilności wstecznej.

Jeśli coś jest jeszcze niejasne, polecam sprawdzić tę stronę , która wyjaśnia powyższe bardziej szczegółowo.

( * ) zauważ, że jest to prawdą tylko do wersji Java 1.8, która wprowadza pojęcie metod default zdefiniowanych w interfejsie.