Разница между SPI и API?

Из эффективной Java, 2-е издание:

Инфраструктура поставщика услуг - это система, в которой несколько поставщиков услуг реализуют услугу, и система делает реализации доступными для своих клиентов, отделяя их от реализаций.

Существуют три основных компонента структуры поставщика услуг: интерфейс службы, который реализуют поставщики; API регистрации провайдера, который система использует для регистрации реализаций, предоставляя клиентам доступ к ним; и API доступа к сервису, который клиенты используют для получения экземпляра сервиса. API доступа к сервису обычно позволяет, но не требует от клиента указывать некоторые критерии для выбора поставщика. При отсутствии такой спецификации API возвращает экземпляр реализации по умолчанию. API доступа к сервису - это "гибкая статическая фабрика", которая формирует основу платформы поставщика услуг.

Необязательным четвертым компонентом структуры поставщика услуг является интерфейс поставщика услуг, который поставщики реализуют для создания экземпляров своей реализации сервиса. В отсутствие интерфейса поставщика услуг реализации регистрируются по имени класса и создаются рефлексивно (Элемент 53). В случае JDBC Connection играет роль интерфейса службы, DriverManager.registerDriver - это API регистрации поставщика, DriverManager.getConnection - это API доступа к службе, а Driver - интерфейс поставщика службы.

Существует множество вариантов шаблона структуры поставщика услуг. Например, API доступа к сервису может вернуть более богатый интерфейс сервиса, чем тот, который требуется от провайдера, используя шаблон адаптера [Gamma95, p. 139]. Вот простая реализация с интерфейсом поставщика услуг и поставщиком по умолчанию:

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

Разница между API и SPI возникает, когда API дополнительно предоставляет некоторые конкретные реализации. В этом случае поставщик услуг должен реализовать несколько API (называемых SPI).

Примером является JNDI:

JNDI предоставляет интерфейсы и некоторые классы для поиска по контексту. Способ поиска контекста по умолчанию предоставляется в IntialContext. Этот класс внутренне будет использовать интерфейсы SPI (используя NamingManager) для конкретных реализаций провайдера.

Посмотрите Архитектуру JNDI ниже для лучшего понимания.

API означает интерфейс прикладного программирования, где API - это средство для доступа к сервису/функции, предоставляемому каким-либо программным обеспечением или платформой.

SPI означает интерфейс поставщика услуг, где SPI - это способ внедрения, расширения или изменения поведения программного обеспечения или платформы.

API обычно предназначен для клиентов для доступа к службе и имеет следующие свойства:

- > API - это программный способ доступа к службе для достижения определенного поведения или вывода

- > С точки зрения эволюции API, добавление вообще не проблема для клиентов

- > Но API, однажды используемый клиентами, он не может (и не должен) быть изменен/удален  за исключением случаев, когда имеется соответствующая связь, поскольку ее полная деградация  ожидания клиента

SPI с другой стороны предназначены для поставщиков и имеют следующие свойства:

- > SPI - это способ расширить/изменить поведение программного обеспечения или платформы (программируемые против.  программный)

- > Развитие SPI отличается от эволюции API, при удалении SPI не проблема

- > Добавление интерфейсов SPI вызовет проблемы и может нарушить существующие реализации

Для получения дополнительной информации нажмите здесь: Интерфейс поставщика услуг

Часто задаваемые вопросы NetBeans: Что такое SPI? Как это отличается от API?

API - это общий термин - аббревиатура для интерфейса прикладного программирования - это означает что-то (в Java, как правило, некоторые классы Java) часть программного обеспечения предоставляет, что позволяет другому программному сообществу общаться с ним.

SPI означает интерфейс поставщика услуг. Это подмножество всех вещей, которые могут быть специфичными для API в ситуациях, когда библиотека предоставляет классы, вызываемые приложением (или библиотекой API), и которые обычно изменяют то, что приложение может сделать.

Классическим примером является JavaMail. Его API имеет две стороны:

• Сторона API - которую вы вызываете, если вы пишете почтовый клиент или хотите прочитать почтовый ящик
• Сторона SPI, если вы предоставляете обработчик проводного протокола, чтобы позволить JavaMail разговаривать с сервером нового типа, например, с новостями или сервером IMAP.

Пользователям API редко приходится видеть или разговаривать с классами SPI и наоборот.

В NetBeans, когда вы видите термин SPI, обычно говорят о классах, которые модуль может вводить во время выполнения, что позволяет NetBeans делать что-то новое. Например, существует общий SPI для реализации систем управления версиями. Различные модули обеспечивают реализацию этого SPI для систем CVS, Subversion, Mercurial и других систем контроля версий. Тем не менее, код, который имеет дело с файлами (сторона API), не нуждается в заботе, есть ли система контроля версий или что это такое.

Интерфейс поставщика услуг - это служебный интерфейс, который должны выполнять все поставщики. Если ни одна из существующих реализаций провайдера не работает для вас, вам необходимо написать собственный поставщик услуг (реализация интерфейса службы) и зарегистрировать где-нибудь (см. Полезный пост от Roman).

Если вы повторно используете существующую реализацию сервис-интерфейса поставщика, вы в основном используете API этого конкретного провайдера, который включает в себя все методы интерфейса службы и несколько собственных собственных методов. Если вы используете методы API-провайдера вне SPI, вы используете специальные функции поставщика.

Я полагаю, что SPI слоты в большую систему, реализуя определенные функции API, а затем регистрируется как доступный через механизмы поиска службы. API напрямую используется кодом приложения конечного пользователя, но может интегрировать компоненты SPI. Это разница между инкапсуляцией и прямым использованием.

Существует один аспект, который, как представляется, не выделяется много, но очень важно понять аргументы в пользу существования разделения API/SPI.

Разделение API/SPI требуется только тогда, когда платформа будет развиваться. Если вы пишете API и "знаете", это не потребует каких-либо будущих улучшений, нет реальных причин для разделения ваш код в две части (помимо создания чистого объекта).

Но это почти никогда не бывает, и люди должны иметь свободу для разработки API вместе с будущими требованиями - в обратном режиме.

Обратите внимание, что все вышеперечисленное предполагает, что вы создаете платформу, которую другие люди используют и/или расширяют, а не свой собственный API, где у вас есть все клиентский код под контролем и, таким образом, можно реорганизовать, как вам нужно.

Позволяет показать его на одном из известных Java-объектов Collection и Collections.

API: Collections - это набор статических методов утилиты. Часто классы, представляющие объект API, определяются как final, поскольку он обеспечивает (во время компиляции), что ни один клиент не может "реализовать" этот объект, и они могут зависеть от "вызова" его статических методов, например.

Collections.emptySet();

Поскольку все клиенты "вызывают", но не "реализуют", авторы JDK могут добавлять новые методы в объект Collections в будущей версии JDK. Они могут быть уверены, что он не может сломать любого клиента, даже если есть, возможно, миллионы обычаев.

SPI: Collection - это интерфейс, который подразумевает, что любой может реализовать свою собственную версию. Таким образом, авторы JDK не могут добавить в него новые методы, поскольку это сломает всех клиентов, которые написали собственную реализацию Collection (*).

Обычно, когда требуется добавить дополнительный метод, новый интерфейс, например, Collection2, который расширяет первый, необходимо создать. Затем клиент SPI может решить, следует ли перейти на новую версию SPI и реализовать ее дополнительный метод или придерживаться старого.

Возможно, вы уже видели это. Если вы объедините обе части вместе в один класс, ваш API будет заблокирован от любых дополнений. Это также причина, по которой хорошие Java API и Frameworks не раскрывают abstract class, поскольку они блокировали бы их дальнейшую эволюцию в отношении обратной совместимости.

Если что-то еще неясно, я рекомендую проверить эту страницу, которая объясняет это более подробно.

(*) Обратите внимание, что это верно только до Java 1.8, который вводит понятие методов default, определенных в интерфейсе.

В мире Java различные технологии должны быть модульными и "подключаемыми" к серверу приложений. Тогда существует разница между

• сервер приложений
  • [SPI]
• подключаемая технология
  • [API]
• приложение конечного пользователя

Двумя примерами таких технологий являются JTA (менеджер транзакций) и JCA (адаптер для JMS или базы данных). Но есть и другие.

Разработчик такой подключаемой технологии должен затем реализовать SPI для подключения в приложении. сервер и предоставить API, который будет использоваться приложением конечного пользователя. Примером из JCA является ManagedConnection интерфейс, который является частью SPI, и Connection, который является частью API конечного пользователя.

API означает интерфейс прикладного программирования, где API - это средство доступа к услуге/функции, предоставляемой каким-либо программным обеспечением или платформой.

SPI расшифровывается как Service Provider Interface, где SPI - это способ внедрения, расширения или изменения поведения программного обеспечения или платформы.

Существует два типа API-интерфейсов: публичный и приватный.

Публичный API - это, пожалуй, первое, что приходит на ум, когда вы думаете об API: Twitter API, Facebook API, Google Maps API и многое другое. Но это лишь малая часть API, которые существуют в сети. Хотя о них вы можете и не слышать, частные API встречаются гораздо чаще (и, возможно, даже выгоднее с точки зрения бизнеса). Публичные API-интерфейсы гораздо более ограничены в ресурсах, которыми они делятся, поскольку они делятся ими публично с разработчиками в Интернете. Частные API - это продуктивность, партнерские отношения и поддержка сервис-ориентированных архитектур.

Частные API-интерфейсы революционизируют процесс работы внутри компаний. Предоставляя открытую архитектуру, частные API-интерфейсы предоставляют разработчикам простой способ подключения непосредственно к серверным системам, данным и программному обеспечению, позволяя командам разработчиков выполнять свою работу за меньшее время и с меньшими ресурсами. Это как пользовательский опыт самообслуживания для внутренних разработчиков.

Открытые API - это все, что позволяет проникнуть во внешний мир. Они предоставляют набор инструкций и стандартов для доступа к информации и службам, которыми обмениваются, позволяя внешним разработчикам создавать приложения на основе этих ресурсов. Вся эта концепция (и API в целом) несколько заимствована из идеи программного обеспечения с открытым исходным кодом: создайте его, откройте для пользователей, а затем позвольте им работать с ним.

Здесь вы будете лучше понимать разницу между SPI и API https://youtu.be/9uaHOGdqH3A