Skirtumas tarp SPI ir API?

Koks skirtumas tarp paslaugų teikėjo sąsajos (SPI) ir taikomųjų programų programavimo sąsajos (API) ?

Visų pirma, ką daro „Java“ bibliotekos, ką daro jų API ir (arba) SPI?

269
02 июня '10 в 4:02 2010-06-02 04:02 kctang yra nustatytas birželio 02 '10, 4:02 2010-06-02 04:02
@ 10 atsakymų
  • API yra klasių / sąsajų / metodų / ..., kuriuos skambinate ir naudojate, kad pasiektumėte tikslą, aprašymas, ir
  • SPI yra klasių / sąsajų / metodų / ... aprašymas, kurį norite išplėsti ir įgyvendinti, kad pasiektumėte tikslą.

Kitaip tariant, API nurodo, ką tam tikra klasė / metodas jums tinka, ir SPI jums pasakys, ką reikia padaryti, kad atitiktų.

API ir SPI paprastai yra atskiri. Pavyzdžiui, „JDBC Driver klasė yra SPI dalis: jei norite naudoti tik JDBC, jums nereikia jo tiesiogiai naudoti, bet kiekvienas, įgyvendinantis JDBC tvarkyklę, turi įgyvendinti šią klasę.

Kartais jie sutampa. Connection sąsaja yra tiek SPI, tiek API: paprastai naudojate JDBC tvarkyklę ir ją turi įdiegti JDBC tvarkyklės kūrėjas.

342
02 июня '10 в 13:30 2010-06-02 13:30 Atsakymą pateikė Joachim Sauer birželio 2 d. 10 val. 13:30 2010-06-02 13:30

Iš veiksmingo „Java“, antras leidimas:

Paslaugų teikėjo infrastruktūra yra sistema, kurioje keli paslaugų teikėjai diegia paslaugą, o sistema leidžia savo klientams įgyvendinti jas atskiriant nuo diegimo.

Yra trys pagrindiniai paslaugų teikėjo struktūros komponentai: paslaugų sąsaja, kurią teikia paslaugų teikėjai; API teikėjo registracija, kurią sistema naudoja registravimui, suteikdama klientams prieigą prie jų; ir paslaugų prieigos API, kurią klientai naudoja paslaugų egzemplioriui gauti. API prieiga prie paslaugos paprastai leidžia, bet nereikalauja, kad klientas nurodytų kai kuriuos paslaugų teikėjo pasirinkimo kriterijus. Jei tokios specifikacijos nėra, API grąžina numatytąjį įgyvendinimo pavyzdį. Paslaugų prieigos API yra „lanksti statinė gamykla“, kuri yra paslaugų teikėjo platformos pagrindas.

Neprivalomas ketvirtasis paslaugų teikėjo struktūros komponentas yra paslaugų teikėjo sąsaja, kurią pardavėjai įdiegia, kad sukurtų jų paslaugų diegimo atvejus. Nesant sąsajos, įgyvendinimo paslaugų teikėjas yra registruojamas pagal klasės pavadinimą ir sukurtas refleksyviai (Elementas 53). JDBC atveju, „Connection“ atlieka paslaugų sąsajos vaidmenį, „DriverManager.registerDriver“ yra teikėjo registracijos API, „DriverManager.getConnection“ yra paslaugų prieigos API, o tvarkyklė yra paslaugų teikėjo sąsaja.

Yra daug paslaugų teikėjo struktūros variantų. Pavyzdžiui, paslaugų prieigos API gali sugrąžinti turtingesnę paslaugų sąsają, nei reikalaujama iš teikėjo naudojant adapterio modelį [Gamma95, p. 139]. Štai paprastas diegimas su paslaugų teikėjo sąsaja ir numatytuoju teikėju:

border=0
 // 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(); } } 
49
02 июня '10 в 13:54 2010-06-02 13:54 atsakymas pateikiamas romėnų 02 birželio 10 d. 13:54 2010-06-02 13:54

Skirtumas tarp API ir SPI atsiranda tada, kai API papildomai pateikia tam tikras konkrečias realizacijas. Tokiu atveju paslaugų teikėjas turi įdiegti kelias API (vadinamas SPI).

Pavyzdys yra JNDI:

JNDI suteikia sąsajas ir tam tikras klases pagal paiešką. Numatytasis konteksto paieškos metodas pateikiamas „IntialContext“. Ši klasė viduje naudos SPI sąsajas (naudodamas „NamingManager“) tam tikriems paslaugų teikėjams.

Norėdami geriau suprasti, žr. Toliau pateiktą JNDI architektūrą.

2019

18
06 июля '13 в 14:10 2013-07-06 14:10 atsakymą pateikė Sandeepas Jindalas liepos 13 d. 13 val. 14.10 val. 2013-07-06 14:10

API nurodo taikomųjų programų programavimo sąsają, kur API yra priemonė naudotis tam tikros programinės įrangos ar platformos teikiama paslauga / funkcija.

SPI reiškia paslaugų teikėjo sąsają, kurioje SPI yra būdas įdiegti, išplėsti ar keisti programinės įrangos ar platformos elgesį.

Paprastai API yra skirta klientams naudotis paslauga ir turi šias savybes:

-> API yra programinis būdas pasiekti paslaugą, kad būtų pasiektas konkretus elgesys ar išėjimas

-> Kalbant apie API raidą, pridėjimas nėra problema klientams.

-> Bet API, kai ją naudoja klientai, ji negali būti (ir neturėtų būti) pakeista / ištrinti, nebent yra atitinkama nuoroda, nes jos visiškas klientų lūkesčių blogėjimas

Kita vertus, SPI yra skirti tiekėjams ir turi šias savybes:

-> SPI - tai būdas išplėsti / keisti programinės įrangos ar platformos elgseną (programuojamas vs programinė įranga)

-> SPI plėtra skiriasi nuo API raidos, o SPI pašalinimas nėra problema

-> SPI sąsajų pridėjimas sukels problemų ir gali sutrikdyti esamus diegimus

Daugiau informacijos rasite čia: Paslaugų teikėjo sąsaja

16
12 нояб. Venkata Aditya Pavan atsakymas lapkričio 12 d 2013-11-12 16:25 '13, 16:25, 2013-11-12 16:25

NetBeans Dažniausiai užduodami klausimai: Kas yra SPI? Kaip tai skiriasi nuo API?

API yra bendras terminas - programos programavimo sąsajos santrumpa - tai reiškia kažką („Java“ paprastai kai kurios „Java“ klasės) suteikia programinės įrangos, kuri leidžia kitai programinės įrangos bendruomenei bendrauti su juo.

SPI reiškia paslaugų teikėjo sąsają. Tai yra visų dalykų pogrupis, kuris gali būti būdingas API, tais atvejais, kai biblioteka atskleidžia taikomąsias programas (arba API biblioteką) ir paprastai pakeičia tai, ką gali padaryti programa.

Klasikinis pavyzdys yra „JavaMail“. Jo API turi dvi puses:

  • API pusė, kurią skambinate, jei rašote el. Pašto klientą arba norite skaityti pašto dėžutę
  • SPI pusė, jei teikiate laidų protokolo tvarkyklę, kad „JavaMail“ galėtų kalbėti su naujo tipo serveriu, pvz., Naujienas ar IMAP serverį.

API vartotojai retai turi matyti ar kalbėti su SPI klasėmis ir atvirkščiai.

„NetBeans“, kai matote terminą SPI, paprastai kalbate apie klases, kurias modulis gali įvesti vykdymo metu, o tai leidžia „NetBeans“ daryti kažką naujo. Pavyzdžiui, versijos valdymo sistemoms įgyvendinti yra bendra SPI. Įvairūs moduliai užtikrina šios SPI įgyvendinimą CVS, Subversion, Mercurial ir kitoms versijų valdymo sistemoms. Tačiau kodą, kuriame aptariami failai (API pusė), nereikia rūpintis, ar yra versijos valdymo sistema, ar tai, kas ji yra.

11
23 июля '11 в 18:22 2011-07-23 18:22 atsakymą pateikė Ondra Žižka, liepos 23 d., 11 d., 18: 22 val. 2011-07-23 18:22

Manau, kad SPI laiko tarpsniai įeina į didelę sistemą, įgyvendindami tam tikras API funkcijas, ir tada užregistruotos kaip prieinamos per paslaugų paieškos mechanizmus. API tiesiogiai naudoja galutinio vartotojo programos kodas, tačiau jis gali integruoti SPI komponentus. Tai skirtumas tarp kapsulių ir tiesioginio naudojimo.

4
02 июня '10 в 4:08 2010-06-02 04:08 atsakymas, kurį pateikė Chris Dennett birželio 2 d. 10 d., 04:08 2010-06-02 04:08

Paslaugų teikėjo sąsaja yra paslaugų sąsaja, kurią turi vykdyti visi paslaugų teikėjai. Jei nė vienas iš esamų teikėjų diegimų jums nepadeda, turite parašyti savo paslaugų teikėją (paslaugų sąsajos diegimą) ir užsiregistruoti kažkur (žr. „Naudingas pranešimas iš romėnų“).

Jei pakartotinai naudosite esamą paslaugų teikėjo sąsajos įgyvendinimą, dažniausiai naudojate šio konkretaus paslaugų teikėjo API, kuris apima visus paslaugų sąsajos metodus ir kelis savo metodus. Jei naudojate API teikėjo metodus ne SPI, naudojate specialias teikėjo funkcijas.

4
26 июля '11 в 17:47 2011-07-26 17:47 atsakymą pateikė tapasvi , liepos 26 d. 11, 17:47 2011-07-26 17:47

Yra vienas aspektas, kuris neatrodo labai išsiskiriantis, tačiau labai svarbu suprasti argumentus, kuriais remiasi API / SPI atskyrimas.

API / SPI atskyrimas reikalingas tik tada, kai platforma vystosi. Jei rašote API ir „know“, tai nereikės atlikti jokių papildomų patobulinimų, nėra jokių realių priežasčių kodą padalyti į dvi dalis (be to, kuriant švarų objektą).

Bet tai beveik niekada nėra, ir žmonės turėtų turėti laisvę kurti API kartu su būsimais reikalavimais - atvirkščiai.

Atkreipkite dėmesį, kad visa tai reiškia, kad jūs sukuriate platformą, kurią kiti žmonės naudoja ir (arba) praplečia, o ne savo API, kur jūs valdote visą kliento kodą ir todėl gali būti pertvarkytas taip, kaip jums reikia.

Leidžia jį rodyti viename iš gerai žinomų „Java“ objektų Collection ir Collections .


API: Collections yra statinių naudingumo metodų rinkinys. Dažnai API objektą reprezentuojančios klasės yra apibrėžtos kaip final , nes užtikrina (kompiliavimo metu), kad nė vienas klientas negali „įgyvendinti“ šio objekto, ir jie gali priklausyti nuo „statinio“ metodų „įkvėpimo“.

 Collections.emptySet(); 

Kadangi visi klientai „skambina“, bet ne „įgyvendina“, JDK autoriai gali Collections naujus metodus Collections objektui būsimoje JDK versijoje. Jie gali būti tikri, kad jis negali nutraukti bet kokio kliento, net jei galbūt yra milijonai muitinės.


SPI: Collection yra sąsaja, kuri reiškia, kad kiekvienas gali įgyvendinti savo versiją. Taigi JDK autoriai negali pridėti naujų metodų , nes tai lūžtų visus klientus, kurie parašė savo Collection (*).

Paprastai, kai jums reikia pridėti papildomą metodą, reikia sukurti naują sąsają, pvz., Collection2 , kuri išplečia pirmąją. Tuomet SPI klientas gali nuspręsti, ar atnaujinti į naują SPI versiją, ir įgyvendinti papildomą metodą arba laikytis senojo.


Galbūt jau matėte tai. Jei sujungiate abi dalis į vieną klasę, jūsų API bus užblokuota nuo bet kokių papildymų. Tai taip pat yra priežastis, kodėl geri „Java“ API ir „Frameworks“ neatskleidžia abstract class , nes jie blokuotų jų tolesnę raidą, atsižvelgiant į atgalinį suderinamumą.

Jei kas nors dar neaišku, aš rekomenduoju patikrinti šį puslapį , kuris išsamiau paaiškina.


(*) Atkreipkite dėmesį, kad tai pasakytina tik prieš „Java 1.8“, kuri įveda sąsajoje apibrėžtą default metodų koncepciją.

2
03 нояб. Atsakymas, kurį pateikė Martin Janíček 03.11 . 2017-11-03 02:14 '17 at 2:14 2017-11-03 02:14

„Java“ pasaulyje įvairios technologijos turi būti modulinės ir „prijungiamos“ prie taikomųjų programų serverio. Tada yra skirtumas tarp

  • programos serverio
    • [SPI]
  • susijusios technologijos
    • [API]
  • galutinio vartotojo taikymas

Du tokių technologijų pavyzdžiai yra JTA (sandorių tvarkytojas) ir JCA (JMS arba duomenų bazės adapteris). Tačiau yra ir kitų.

Tokios „plug-in“ technologijos kūrėjas turi įdiegti SPI prisijungimui programoje. serverį ir pateikite API, kuri bus naudojama galutinio vartotojo programoje. JCA pavyzdys yra „ ManagedConnection“ sąsaja, kuri yra SPI dalis, ir „ Connection“ , kuri yra galutinio vartotojo API dalis.

2
02 июня '10 в 10:17 2010-06-02 10:17 atsakymas pateikiamas ewernli birželio 2 d. 10 val. 10:17 2010-06-02 10:17

API - tai programų programavimo sąsaja, kur API yra priemonė, skirta prieigai prie programinės įrangos ar platformos teikiamos paslaugos / funkcijos.

SPI reiškia „Paslaugų teikėjo sąsają“, kurioje SPI yra būdas įdiegti, išplėsti ar keisti programinės įrangos ar platformos elgesį.

Yra dviejų tipų API: viešieji ir privatūs.

Viešoji API yra tikriausiai pirmas dalykas, į kurį galvojate apie API: „Twitter“ API, „Facebook“ API, „Google“ žemėlapių API ir dar daugiau. Tačiau tai tik nedidelė API dalis, esanti tinkle. Nors jūs negalite išgirsti apie juos, privačios API yra daug dažniau (ir, galbūt, dar labiau pelningos verslo požiūriu). Viešos API yra daug ribotesnės, nes jomis dalijamasi, nes jos viešai platinamos su kūrėjais internete. Privatūs API yra produktyvumas, partnerystė ir palaikymas į paslaugas orientuotoms architektūroms.

Privatūs API sukelia revoliuciją įmonių darbo procese. Teikdami atvirą architektūrą, privačios API suteikia kūrėjams paprastą būdą tiesiogiai prisijungti prie serverio sistemų, duomenų ir programinės įrangos, leidžiančios vystymo komandoms užbaigti darbą per trumpesnį laiką ir mažiau išteklių. Tai tarsi vidaus paslaugų teikėjų savitarnos vartotojų patirtis.

Atviras API yra viskas, kas leidžia įsiskverbti į išorinį pasaulį. Juose pateikiamos informacijos ir paslaugų, kuriomis keičiamasi, prieigos instrukcijų ir standartų rinkinys, leidžiantis išoriniams kūrėjams kurti programas, pagrįstas šiais ištekliais. Visa ši koncepcija (ir visa API) yra šiek tiek pasiskolinta iš atviro kodo programinės įrangos idėjos: sukurkite ją, atidarykite ją vartotojams ir leiskite jiems dirbti su juo.

Čia geriau suprasite skirtumą tarp SPI ir API https://youtu.be/9uaHOGdqH3A

0
22 дек. atsakymas suteiktas Olivier 22 d. 2018-12-22 01:20 '18 ne 1:20 2018-12-22 01:20

Kiti klausimai apie žymes arba Užduoti klausimą