SPI और API के बीच अंतर?

Question

सेवा प्रदाता इंटरफ़ेस (SPI) और अनुप्रयोग प्रोग्रामिंग इंटरफ़ेस (API) के बीच क्या अंतर है ?

अधिक विशेष रूप से, जावा पुस्तकालयों के लिए, क्या उन्हें एपीआई और / या एसपीआई बनाता है?

Answer 1

• एपीआई कक्षाओं / इंटरफेस / विधियों / ... का वर्णन है जिसे आप लक्ष्य प्राप्त करने के लिए कॉल और उपयोग करते हैं, और
• SPI कक्षाओं / इंटरफेस / विधियों / ... का वर्णन है जो आप एक लक्ष्य को प्राप्त करने के लिए बढ़ाते हैं और लागू करते हैं।

अलग तरीके से कहें, तो एपीआई आपको बताता है कि एक विशिष्ट वर्ग / विधि आपके लिए क्या करती है, और एसपीआई आपको बताता है कि आपको क्या करना चाहिए।

आमतौर पर एपीआई और एसपीआई अलग-अलग होते हैं। उदाहरण के लिए, JDBC में Driverवर्ग SPI का हिस्सा है: यदि आप बस JDBC का उपयोग करना चाहते हैं, तो आपको इसे सीधे उपयोग करने की आवश्यकता नहीं है, लेकिन जो भी JDBC ड्राइवर लागू करता है, उसे उस वर्ग को लागू करना चाहिए।

हालांकि, वे कभी-कभी ओवरलैप करते हैं। इंटरफेस है दोनों एसपीआई और एपीआई: आप इसे नियमित रूप से उपयोग करें जब आप एक JDBC ड्राइवर का उपयोग करें और यह JDBC ड्राइवर के विकासकर्ता द्वारा कार्यान्वित किया जाना चाहिए।Connection

Comments

के बारे में सही लगता है। बस इतना है कि SPI और API के बीच की रेखा थोड़ी ग्रे हो सकती है क्योंकि अधिकांश API में अपने उपयोगकर्ता के लिए अमूर्त वर्ग / इंटरफेस होते हैं ताकि चीजें ठीक हो

— सकें

@koss: सबसे एपीआई? मुझे पता है कि आपका क्या मतलब है, लेकिन मैं उन चीजों को बहुत ज्यादा नहीं देखता।

— जोकिम सॉर

SPI विक्रेताओं के लिए एपीआई अधिक डेवलपर्स है।

— अज़फ़र नियाज़

@AzfarNiaz: ठीक है, क्योंकि विक्रेताओं ने अपने उत्पादों को बनाने के लिए डेवलपर्स को नियुक्त किया है, जो दोनों डेवलपर्स के लिए प्रासंगिक हैं ;-)

— जोकिम सउर

जावा में, एनोटेशन एक एसपीआई का हिस्सा हैं? उदाहरण के लिए, अगर मुझे @SomeAnnotationइसे किसी फ्रेमवर्क द्वारा प्राप्त करने के लिए अपनी कक्षा में जोड़ना है, तो क्या इस एनोटेशन वर्ग SomeAnnotation.classको SPI का हिस्सा माना जाएगा, भले ही मैं तकनीकी रूप से इसका विस्तार या कार्यान्वयन नहीं कर रहा हूं?

— एडम बुर्ले

Answer 2

से प्रभावी जावा, 2 संस्करण :

एक सेवा प्रदाता ढांचा एक प्रणाली है जिसमें कई सेवा प्रदाता एक सेवा को लागू करते हैं, और यह प्रणाली अपने ग्राहकों के लिए कार्यान्वयन को उपलब्ध कराती है, उन्हें क्रियान्वयन से अलग करती है।

एक सेवा प्रदाता ढांचे के तीन आवश्यक घटक हैं: एक सेवा इंटरफ़ेस, जिसे प्रदाता कार्यान्वित करते हैं; एक प्रदाता पंजीकरण एपीआई, जो सिस्टम कार्यान्वयन को पंजीकृत करने के लिए उपयोग करता है, ग्राहकों को उन तक पहुंच प्रदान करता है; और एक सेवा एक्सेस एपीआई, जो ग्राहक सेवा का एक उदाहरण प्राप्त करने के लिए उपयोग करते हैं। सेवा एक्सेस एपीआई आमतौर पर अनुमति देता है लेकिन प्रदाता को चुनने के लिए ग्राहक को कुछ मानदंडों को निर्दिष्ट करने की आवश्यकता नहीं होती है। इस तरह के विनिर्देश के अभाव में, एपीआई एक डिफ़ॉल्ट कार्यान्वयन का एक उदाहरण देता है। सेवा पहुंच एपीआई "लचीला स्थिर कारखाना" है जो सेवा प्रदाता ढांचे का आधार बनता है।

सेवा प्रदाता फ्रेमवर्क का एक वैकल्पिक चौथा घटक एक सेवा प्रदाता इंटरफ़ेस है, जो प्रदाता अपने सेवा कार्यान्वयन के उदाहरण बनाने के लिए कार्यान्वित करते हैं। एक सेवा प्रदाता इंटरफ़ेस की अनुपस्थिति में, कार्यान्वयन को वर्ग के नाम से पंजीकृत किया जाता है और तुरंत प्रतिबिंबित (आइटम 53) किया जाता है। JDBC के मामले में, कनेक्शन सेवा इंटरफ़ेस का हिस्सा निभाता है, DriverManager.registerDriver प्रदाता पंजीकरण API है, DriverManager.getConnection सेवा एक्सेस API है, और ड्राइवर सेवा प्रदाता इंटरफ़ेस है।

सर्विस प्रोवाइडर फ्रेमवर्क पैटर्न के कई वेरिएंट हैं। उदाहरण के लिए, सेवा एक्सेस एपीआई, एडेप्टर पैटर्न [गामा 95, पी का उपयोग करके प्रदाता की आवश्यकता के मुकाबले एक अमीर सेवा इंटरफ़ेस वापस कर सकता है। 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();
    }
}

Comments

सेवा प्रदाता ढांचे पर बहुत अच्छे वर्णन के लिए धन्यवाद। यह जानना उपयोगी होगा। हालाँकि, यह स्पष्ट रूप से एपीआई और स्पि के बीच "अंतर" का वर्णन नहीं करता है, इसलिए मैं यहां टिक नहीं

— लगाऊंगा

Answer 3

एपीआई और एसपीआई के बीच अंतर तब आता है जब एपीआई अतिरिक्त रूप से कुछ ठोस कार्यान्वयन प्रदान करता है। उस स्थिति में, सेवा प्रदाता को कुछ API को लागू करना होगा (जिसे SPI कहा जाता है)

एक उदाहरण JNDI है:

JNDI संदर्भ लुकअप के लिए इंटरफेस और कुछ कक्षाएं प्रदान करता है। किसी संदर्भ को देखने का डिफ़ॉल्ट तरीका IntialContext में दिया गया है। प्रदाता विशिष्ट कार्यान्वयन के लिए यह वर्ग आंतरिक रूप से SPI इंटरफेस (NamingManager का उपयोग करके) का उपयोग करेगा।

बेहतर समझ के लिए नीचे JNDI आर्किटेक्चर देखें।

Answer 4

एपीआई एप्लीकेशन प्रोग्रामिंग इंटरफेस के लिए है, जहां एपीआई किसी प्रकार के सॉफ्टवेयर या एक मंच द्वारा प्रदान की जाने वाली सेवा / फ़ंक्शन तक पहुंचने का एक साधन है।

SPI सेवा प्रदाता इंटरफ़ेस के लिए है, जहाँ SPI सॉफ़्टवेयर या प्लेटफ़ॉर्म के लिए व्यवहार को इंजेक्ट, विस्तारित या परिवर्तित करने का तरीका है।

एपीआई आम तौर पर एक सेवा का उपयोग करने के लिए ग्राहकों के लिए लक्ष्य है और इसमें निम्नलिखित गुण हैं:

-> एपीआई एक निश्चित व्यवहार या आउटपुट प्राप्त करने के लिए किसी सेवा तक पहुंचने का एक प्रोग्रामेटिक तरीका है

-> एपीआई विकास के दृष्टिकोण से, इसके अलावा ग्राहकों के लिए कोई समस्या नहीं है

-> लेकिन API का ग्राहकों द्वारा उपयोग किए जाने के बाद (जब तक उचित संचार न हो, तब तक इसे बदल नहीं सकता / हटा दिया जा सकता है, क्योंकि ग्राहक की पूरी उम्मीद नहीं है)

दूसरे भाग पर SPI प्रदाताओं के लिए लक्षित है और निम्नलिखित गुण हैं:

-> एसपीआई एक सॉफ्टवेयर या एक प्लेटफॉर्म (प्रोग्राम बनाम प्रोग्रामेटिक) के व्यवहार को बढ़ाने / बदलने का एक तरीका है

-> SPI विकास एपीआई विकास से अलग है, SPI हटाने में कोई समस्या नहीं है

-> एसपीआई इंटरफेस को जोड़ने से समस्याएं पैदा होंगी और मौजूदा कार्यान्वयन टूट सकते हैं

अधिक स्पष्टीकरण के लिए यहां क्लिक करें: सेवा प्रदाता इंटरफ़ेस

Answer 5

NetBeans 'FAQ: एक SPI क्या है? यह एपीआई से कैसे अलग है?

एपीआई एक सामान्य शब्द है - एप्लिकेशन प्रोग्रामिंग इंटरफ़ेस के लिए एक संक्षिप्त रूप - इसका मतलब कुछ है (जावा में, आमतौर पर कुछ जावा कक्षाएं) सॉफ्टवेयर का एक टुकड़ा उजागर होता है, जो अन्य सॉफ़्टवेयर को इसके साथ संवाद करने की अनुमति देता है।

SPI का मतलब सर्विस प्रोवाइडर इंटरफेस है। यह उन सभी चीजों का एक सबसेट है, जो एपीआई के लिए उन स्थितियों के लिए विशिष्ट हो सकते हैं, जहां एक लाइब्रेरी उन कक्षाओं को प्रदान कर रही है, जिन्हें एप्लिकेशन (या एपीआई लाइब्रेरी) कहा जाता है, और जो आमतौर पर उन चीजों को बदलते हैं जो एप्लिकेशन करने में सक्षम है।

क्लासिक उदाहरण JavaMail है। इसके API के दो पहलू हैं:

• एपीआई साइड - जिसे आप कॉल करते हैं यदि आप मेल क्लाइंट लिख रहे हैं या मेलबॉक्स पढ़ना चाहते हैं
• SPI पक्ष यदि आप JavaMail को किसी समाचार या IMAP सर्वर जैसे नए प्रकार के सर्वर से बात करने की अनुमति देने के लिए वायर-प्रोटोकॉल हैंडलर प्रदान कर रहे हैं

एपीआई के उपयोगकर्ताओं को शायद ही कभी एसपीआई कक्षाओं और इसके विपरीत बात करने या देखने की जरूरत होती है।

नेटबीन्स में, जब आप एसपीआई शब्द देखते हैं, तो यह आमतौर पर उन वर्गों के बारे में बात कर रहा है जो एक मॉड्यूल रनटाइम पर इंजेक्ट कर सकते हैं जो नेटबीन्स को नई चीजें करने की अनुमति देते हैं। उदाहरण के लिए, संस्करण नियंत्रण प्रणालियों को लागू करने के लिए एक सामान्य एसपीआई है। विभिन्न मॉड्यूल CVS, सबवर्सन, मर्क्यूरियल और अन्य रिविजन कंट्रोल सिस्टम के लिए उस SPI का कार्यान्वयन प्रदान करते हैं। हालाँकि, कोड जो फ़ाइलों (एपीआई साइड) से संबंधित है, अगर संस्करण नियंत्रण प्रणाली, या यह क्या है, इसकी देखभाल करने की आवश्यकता नहीं है।

Answer 6

ऐसा एक पहलू है, जिस पर ज्यादा प्रकाश नहीं डाला गया है, लेकिन एपीआई / एसपीआई विभाजन के अस्तित्व के पीछे के तर्क को समझना बहुत महत्वपूर्ण है।

API / SPI विभाजन की आवश्यकता तब होती है जब प्लेटफॉर्म के विकसित होने की उम्मीद की जाती है। यदि आप एक एपीआई लिखते हैं और "जानते हैं" तो इसे भविष्य में किसी भी सुधार की आवश्यकता नहीं होगी, आपके कोड को दो भागों में विभाजित करने के लिए (स्वच्छ वस्तु डिजाइन बनाने के अलावा) कोई वास्तविक कारण नहीं है।

लेकिन यह लगभग कभी नहीं होता है और लोगों को भविष्य की आवश्यकताओं के साथ-साथ एक पिछड़े संगत तरीके से एपीआई को विकसित करने की स्वतंत्रता की आवश्यकता होती है।

ध्यान दें कि उपर्युक्त सभी मान लें कि आप ऐसे प्लेटफ़ॉर्म का निर्माण कर रहे हैं जिसे अन्य लोग उपयोग करते हैं और / या अपना स्वयं का एपीआई और नहीं जहां आपके पास नियंत्रण में सभी क्लाइंट कोड हैं और इस प्रकार आपको फिर से रिफ्लेक्टर करना पड़ सकता है।

आइए इसे जाने-माने जावा ऑब्जेक्ट्स में से एक पर दिखाएं Collectionऔर Collections।

---

एपीआई: Collections उपयोगिता स्थैतिक तरीकों का एक सेट है। अक्सर एपीआई ऑब्जेक्ट का प्रतिनिधित्व करने वाली कक्षाओं को परिभाषित किया जाता है finalक्योंकि यह सुनिश्चित करता है (संकलन समय पर) कि कोई ग्राहक कभी भी उस वस्तु को "लागू" नहीं कर सकता है और वे अपने स्थिर तरीकों को "कॉलिंग" पर निर्भर कर सकते हैं , जैसे।

Collections.emptySet();

के बाद से सभी ग्राहकों रहे हैं "को" नहीं बल्कि "को लागू करने" , JDK के लेखक हैं नए तरीके जोड़ करने के लिए स्वतंत्र में CollectionsJDK के भविष्य के संस्करण में वस्तु। वे यह सुनिश्चित कर सकते हैं कि यह किसी भी ग्राहक को नहीं तोड़ सकता है, भले ही वहाँ usages के milions हैं।

---

एसपीआई: Collection एक इंटरफ़ेस है जिसका अर्थ है कि कोई भी अपने स्वयं के संस्करण को लागू कर सकता है। इस प्रकार, JDK के लेखक इसमें नए तरीके नहीं जोड़ सकते क्योंकि यह उन सभी ग्राहकों को तोड़ देगा जिन्होंने अपना स्वयं का Collectionकार्यान्वयन (*) लिखा था ।

आम तौर पर जब अतिरिक्त विधि को जोड़ने की आवश्यकता होती है, तो नया इंटरफ़ेस, जैसे Collection2कि पूर्व को विस्तारित करने की आवश्यकता होती है। एसपीआई क्लाइंट तब तय कर सकता है कि एसपीआई के नए संस्करण में माइग्रेट करना है या इसे लागू करना है या अतिरिक्त तरीका है या पुराने वाले के साथ रहना है या नहीं।

---

आप पहले से ही बिंदु देख सकते हैं। यदि आप दोनों टुकड़ों को एक एकल वर्ग में जोड़ते हैं, तो आपका एपीआई किसी भी अतिरिक्त से अवरुद्ध है। यही कारण है कि अच्छे जावा एपीआई और फ्रेमवर्क उजागर नहीं होते हैं abstract classक्योंकि वे पिछड़े संगतता के संबंध में अपने भविष्य के विकास को रोकते हैं।

यदि कुछ अभी भी स्पष्ट नहीं है, तो मैं इस पृष्ठ को जांचने की सलाह देता हूं जो ऊपर और अधिक विस्तार से बताता है।

---

(*) यह केवल जावा 1.8 तक ही सही है जो defaultएक इंटरफेस में परिभाषित तरीकों की अवधारणा का परिचय देता है।

Answer 7

मुझे लगता है कि एक एपीआई की कुछ विशेषताओं को लागू करके एक SPI स्लॉट को एक बड़ी प्रणाली में बदल दिया जाता है, और फिर सेवा लुकअप तंत्र के माध्यम से उपलब्ध होने के रूप में खुद को पंजीकृत किया जाता है। एक एपीआई का उपयोग सीधे एंड-यूज़र एप्लिकेशन कोड द्वारा किया जाता है, लेकिन यह SPI घटकों को एकीकृत कर सकता है। यह एनकैप्सुलेशन और प्रत्यक्ष उपयोग के बीच का अंतर है।

Comments

प्रतिक्रिया क्रिस के लिए धन्यवाद। मौजूदा जावा (यानी सर्वलेट, JDBC, आदि) पुस्तकालयों के किसी भी उदाहरण? ... जैसे यह कैसे उन्हें एपीआई / एसपीआई बनाता है। अकेले वर्णन के साथ अंतर की कल्पना करना कठिन हो सकता है।

— केक्टंग

एक एपीआई JDBC है, JDBC के लिए एक SPI डेटाबेस कनेक्टर इंटरफ़ेस है जो SPI डेवलपर्स नए डेटाबेस कनेक्टर बनाने के लिए उपयोग कर सकता है जिसे डेवलपर उपयोग के लिए चुन सकता है।

— क्रिस डेनेट

Answer 8

सेवा प्रदाता इंटरफ़ेस सेवा इंटरफ़ेस है जिसे सभी प्रदाताओं को लागू करना चाहिए। यदि मौजूदा प्रदाता कार्यान्वयन में से कोई भी आपके लिए काम नहीं करता है, तो आपको अपना स्वयं का सेवा प्रदाता (सेवा इंटरफ़ेस लागू करना) लिखना होगा और कहीं रजिस्टर करना होगा (रोमन द्वारा उपयोगी पोस्ट देखें)।

यदि आप सेवा इंटरफ़ेस के मौजूदा प्रदाता कार्यान्वयन का पुन: उपयोग कर रहे हैं, तो आप मूल रूप से उस विशेष प्रदाता के एपीआई का उपयोग कर रहे हैं, जिसमें सेवा इंटरफ़ेस की सभी विधियाँ और स्वयं के कुछ सार्वजनिक तरीके शामिल हैं। यदि आप SPI के बाहर प्रदाता API के तरीकों का उपयोग कर रहे हैं, तो आप प्रदाता विशिष्ट सुविधाओं का उपयोग कर रहे हैं।

Answer 9

जावा दुनिया में, विभिन्न तकनीकों को एक अनुप्रयोग सर्वर में मॉड्यूलर और "प्लगेबल" माना जाता है। तब के बीच अंतर है

• अनुप्रयोग सर्वर
  • [एसपीआई]
• प्लग करने योग्य तकनीक
  • [एपीआई]
• अंतिम उपयोगकर्ता आवेदन

ऐसी तकनीकों के दो उदाहरण JTA (लेनदेन प्रबंधक) और JCA (JMS या डेटाबेस के लिए एडाप्टर) हैं। लेकिन और भी हैं।

इस तरह की प्लग करने योग्य तकनीक के कार्यान्वयन के लिए ऐप में एसपीआई को प्लग करने योग्य होना चाहिए। सर्वर और एक एपीआई प्रदान करते हैं जिसका उपयोग एंड-यूज़र एप्लिकेशन द्वारा किया जाता है। JCA का एक उदाहरण ManagedConnection इंटरफ़ेस है जो SPI का हिस्सा है, और कनेक्शन जो एंड-यूज़र API का हिस्सा है।