Rivya API के साथ बहु-माध्यम कार्यप्रवाह बनाएं

एक अच्छा Rivya API एकीकरण सिर्फ एक मॉडल को एक अनुरोध भेजना नहीं होता।

अधिकांश वास्तविक उत्पाद कार्यप्रवाह एक छोटी शृंखला का पालन करते हैं: सही मॉडल चुनना, इनपुट तैयार करना, जरूरत होने पर संदर्भ फ़ाइलें अपलोड करना, कार्य भेजना, उसकी स्थिति देखना, क्रेडिट संभालना और नतीजा तैयार होने पर उत्पाद को सूचना देना।

यह लेख योजना की रूपरेखा दिखाता है। सबसे छोटे चलाए जा सकने वाले मार्ग के लिए Rivya API क्विकस्टार्ट और सटीक अनुरोध फ़ील्ड के लिए API दस्तावेज़ देखें।

नीचे दिया कार्यप्रवाह लागू किए गए सार्वजनिक API एकीकरण अनुबंध को समझाता है। काम शुरू करने से पहले पक्का करें कि व्यवस्था और खाता के लिए सार्वजनिक API चालू है, चुना गया मॉडल API पर इस्तेमाल के लिए तैयार है और वेबहुक जैसी वैकल्पिक सुविधाएं सच में उपलब्ध हैं।

उत्पाद क्षण से शुरू करें

एंडपॉइंट चुनने से पहले उत्पाद में होने वाली कार्रवाई को एक वाक्य में लिखें।

उदाहरण:

• Seller listing brief submit करे तो product image draft create करें।

• Campaign manager still direction approve करे तो short video concept generate करें।

• Internal research tool में chat turn भेजें और response user को stream करें।

• Reference image upload करें, supported model request submit करें और result ready होने पर user को notify करें।

यह वाक्य एकीकरण को बिखरे हुए API अनुरोधों का समूह बनने से रोकता है।

कोड लिखने से पहले कार्यप्रवाह का नक्शा बनाएं

अनुरोध की संरचना खोलने से पहले इस तालिका का उपयोग करें।

कार्यप्रवाह इतना साफ़ होना चाहिए कि हर API क्षेत्र के मौजूद होने का कारण स्पष्ट हो।

चरण 1: एकीकरण के लिए कुंजी तैयार करें

उस खास ऐप, परिवेश या कार्यप्रवाह के लिए API कुंजी बनाएं, जो इसका उपयोग करेगा।

हर चीज के लिए एक ही कुंजी इस्तेमाल न करें। कुंजियों को उनके उद्देश्य के अनुसार नाम देने से बाद की समीक्षा आसान होती है:

• production-image-workflow

• staging-video-tests

• internal-chat-assistant

• webhook-smoke-test

कुंजी सहेजने से पहले API पहचान सत्यापन पढ़ें। पूरा गुप्त मान केवल एक बार दिखाया जाता है, इसलिए टीम को इसे तुरंत सही सर्वर-पक्षीय गुप्त-भंडार में सहेजना चाहिए।

चरण 2: सार्वजनिक API सूची से मॉडल चुनें

किसी मॉडल को केवल इसलिए हार्ड-कोड न करें कि वह मैन्युअल परीक्षण में काम कर गया था।

API मॉडल और मॉडल API संदर्भ से पुष्टि करें करें:

• सार्वजनिक मॉडल ID

• क्या यह API के माध्यम से उपलब्ध है

• समर्थित इनपुट विधि

• प्रॉम्प्ट और पैरामीटर की अपेक्षाएं

• क्या Files API जरूरी है

• क्रेडिट व्यवहार और तैयारी जानकारी

यहां कई एकीकरण अधिक व्यवस्थित हो जाते हैं। Studio में हाथ से जांचने के लिए उपयुक्त मॉडल, स्वचालित उत्पाद प्रक्रिया का सही पहला मॉडल हो यह जरूरी नहीं।

चरण 3: तय करें कि पहले संस्करण में Files API चाहिए या नहीं

अगर मॉडल टेक्स्ट इनपुट से प्रयास कर सकता है, तो पहला संस्करण केवल टेक्स्ट रखें।

Files API तभी जोड़ें, जब कार्यप्रवाह को सच में संदर्भ मीडिया चाहिए।

जरूरत पड़ने पर यह तय करें:

• उत्पाद किस प्रकार की फाइलें स्वीकार करता है

• फाइल सफाई चरण किसके पास है

• अपलोड विफल होने पर क्या होता है

• लौटाई गई फ़ाइल जानकारी मॉडल पैरामीटर में कैसे भेजी जाती है

• एक ही फाइल दोबारा उपयोग होगी या फिर अपलोड होगी

इससे कमजोर फाइल-अनुभव केवल साफ दिखने वाले तैयार बटन के पीछे छिपा नहीं रहता।

चरण 4: जनरेशन कार्य भेजें

इमेज, वीडियो और ऑडियो निर्माण का सामान्य ढांचा यह है:

1. मॉडल ID, प्रॉम्प्ट और समर्थित पैरामीटर तैयार करें

2. सुरक्षित पुनःप्रयास के लिए इडेम्पोटेंसी कुंजी जोड़ें

3. जनरेशन एंडपॉइंट से अनुरोध भेजें

4. सार्वजनिक कार्य ID सुरक्षित रखें

5. कार्य अंतिम स्थिति तक पहुंचने तक उसकी स्थिति पोल करें

अनुरोध आकार के लिए तैयार निर्माण और नतीजा संचालन के लिए निर्माण स्थिति उपयोग करें।

उत्पाद को queued, processing, succeeded और failed को उपयोगकर्ता के लिए दिखाई देने वाली स्थितियों की तरह संभालना चाहिए। उपयोगकर्ता को तैनाती के तकनीकी विवरण न पढ़वाएं और न ही उसे अनुमान लगाने दें कि कार्य धीमा क्यों है।

चरण 5: बातचीत मॉडल के लिए बातचीत API उपयोग करें

बातचीत मॉडल को बातचीत API उपयोग करना चाहिए, निर्माण समापन बिंदु नहीं।

यह इसलिए मायने करता है क्योंकि बातचीत काम का व्यवहार अलग होता है:

• बातचीत के दौर API से बनाए गए सत्र का हिस्सा हो सकते हैं

• बिना स्ट्रीम और SSE स्ट्रीमिंग में उपयोगकर्ता का अनुभव अलग होता है

• इमेज अटैचमेंट Files API से मिली फ़ाइल ID का उपयोग करते हैं

• क्रेडिट का हिसाब सामान्य अतुल्यकालिक माध्यम वाले काम के बजाय बातचीत के दौर के अनुसार चलता है

अगर उत्पाद को अपने इंटरफेस के भीतर सहायक का उत्तर चाहिए, तो बातचीत API सही रास्ता हो सकता है। अगर उपयोगकर्ता अभी विचारों की खोज कर रहा है, तो Rivya चैट या Studio बेहतर हो सकता है।

चरण 6: बार-बार स्थिति जांच से शुरू करें, फिर वेबहुक जोड़ें

पहले संस्करण के लिए बार-बार स्थिति जांच को समझना आसान है।

व्यवस्था में वेबहुक चालू हों, तो API वेबहुक तब जोड़ें जब:

• उत्पाद के पास कई अतुल्यकालिक काम हों

• प्रतीक्षा कर रहे ग्राहक को बार-बार सीधे स्थिति नहीं जांचनी चाहिए

• आगे की प्रणालियों को लॉग इन के बाद पूर्ण होने वाली घटनाएं चाहिए

• पुनःप्रयास और दोहराव का संचालन पहले से तय हो

वेबहुक प्राप्तकर्ता साधारण और कड़े होने चाहिए: हस्ताक्षर सत्यापित करें, दोहराव से सुरक्षित घटनाएं स्वीकार करें, एक उत्पाद रिकॉर्ड अद्यतन करें और केवल सुरक्षित विवरण लॉग करें।

चरण 7: क्रेडिट को उत्पाद में दिखाई देने वाला बनाएं

Rivya API Studio वाले एक ही खाता क्रेडिट उपयोग करता है।

आपका एकीकरण तय करे कि इसमें से कितना दिखाना है। कम से कम टीम को ये बातें पता होनी चाहिए:

• API कुंजी किस खाता के पास है

• कौन-सा कार्यप्रवाह क्रेडिट खर्च कर सकता है

• क्रेडिट बहुत कम होने पर क्या होता है

• विफल निर्माण की स्थिति कैसे समझाई जाती है

• क्रेडिट और बिल सवाल के लिए उपयोगकर्ता को कहां भेजना है

उपयोगकर्ता को दिखाई देने वाले क्रेडिट वॉलेट के लिए API क्रेडिट, Rivya में क्रेडिट और बिलिंग और Rivya क्रेडिट, पैक और प्लान को कैसे समझें देखें।

छोटा पहला संस्करण

अच्छे पहले संस्करण का दायरा जानबूझकर सीमित रखा जाता है।

उदाहरण:

1. एक API कुंजी

2. एक चुना गया चित्र मॉडल

3. अभी फाइल अपलोड नहीं

4. एक निर्माण अनुरोध

5. एक स्थिति बार-बार स्थिति जांच मार्ग

6. आपके उत्पाद में नतीजे का सरल पूर्वावलोकन

7. एक साफ क्रेडिट त्रुटि संदेश

यह संस्करण अधिक घटक जोड़ने से पहले संपर्क और प्रवाह को साबित करता है।

अधिक पूर्ण संस्करण

पहला संस्करण काम करने लगे, तब अधिक पूरा कार्यप्रवाह ये चीजें जोड़ सकता है:

• संदर्भ इमेज या वीडियो के लिए Files API

• मॉडल-विशिष्ट पैरामीटर नियंत्रण

• आपके उत्पाद रिकॉर्ड से जुड़ी इडेम्पोटेंसी

• सुविधा चालू होने पर पूरा होना के लिए प्रवेश किया हुआ वेबहुक

• सहायक की बातचीत के दौर के लिए बातचीत API

• जहां बातचीत को उपलब्ध नतीजा चाहिए, वहां सर्वर-पक्ष की घटना-धारा

• विफल काम के लिए प्रशासन या सहायता दृश्य

हर नई चीज किसी वास्तविक उत्पाद जरूरत का जवाब दे। अगर वह केवल प्रदर्शन को बड़ा दिखाती है, तो उसे छोड़ दें।

सामान्य एकीकरण गलतियां

इन ढांचे से बचें:

• हर API सुविधा से एक साथ शुरू करना

• खाता-मालिक से क्रेडिट उपयोग छिपाना

• API प्रक्रिया में Studio-केवल मान्यताएं उपयोग करना

• फ़ाइल अपलोड को बाद में जोड़ी जाने वाली मामूली चीज मानना

• इडेम्पोटेंसी के बिना निर्माण अनुरोध दोबारा भेजना

• बातचीत API को उन काम के लिए उपयोग करना जिन्हें अतुल्यकालिक निर्माण होना चाहिए

• चैट के दौर के लिए जनरेशन एंडपॉइंट इस्तेमाल करना

• पूरी API कुंजियां, वेबहुक के गुप्त मान या अस्थायी फाइल विवरण लॉग करना

सबसे सुरक्षित API कार्यप्रवाह स्वामित्व, स्थिति और विफलता के संचालन के बारे में स्पष्ट होता है।

आगे कहां जाएं

• सार्वजनिक API केंद्र के लिए डेवलपर से शुरू करें।

• पहला अनुरोध आजमाने के लिए Rivya API की त्वरित शुरुआत इस्तेमाल करें।

• मॉडल आईडी चुनने से पहले API मॉडल देखें।

• Files API तभी उपयोग करें, जब मॉडल को सच में संदर्भ मीडिया चाहिए।

• बातचीत बातचीत के दौर और स्ट्रीमिंग बातचीत जवाब के लिए बातचीत API उपयोग करें।

• बार-बार स्थिति जांच काफी न रहे और वेबहुक पहुंच चालू हो, तो API वेबहुक इस्तेमाल करें।

• अगर कार्यप्रवाह को अभी भी मानवीय खोज चाहिए, तो उसे स्वचालित करने से पहले Studio के बजाय Rivya API कब इस्तेमाल करें पढ़ें।