Cea mai usoara greseala este sa tratezi Rivya API si Rivya Studio ca rute concurente.
Sunt mai usor de inteles ca doua etape ale aceluiasi produs. Studio este locul unde oamenii exploreaza, aleg, revizuiesc si continua vizual munca. API-ul este locul unde un workflow stabil devine parte din alt produs, script sau proces backend.
Daca inca inveti suprafata API, incepe cu Ce este Rivya API?. Aceasta pagina este mai ingusta: cum decizi daca o sarcina concreta apartine in Studio sau in API.
Decizia intr-un singur tabel
| Intrebare | Foloseste Studio cand... | Foloseste API-ul cand... |
|---|---|---|
| Rezultatul este inca exploratoriu? | da | nu, workflowul este deja repetabil |
| O persoana trebuie sa compare rezultate? | da | doar dupa ce aplicatia ta primeste rezultatele |
| Alegerea modelului este stabila? | inca nu | da, sau este selectata din lista de modele API |
| Sarcina are nevoie de media de referinta? | o persoana inca o pregateste | aplicatia ta o poate uploada prin Files API |
| Rezultatul trebuie sa actualizeze alt sistem? | inca nu | da, prin polling sau webhookuri |
| Utilizarea creditelor trebuie sa ramana vizibila? | da, in timpul testarii | da, dar prin controale API la nivel de cont |
Nu este despre care suprafata este mai avansata. Este despre daca sarcina este gata sa fie automatizata.
Foloseste Studio cat timp munca inca se schimba
Studio este locul potrivit cand decizia umana este inca munca principala.
Asta include:
- alegerea intre modele de imagine, video, audio sau chat
- testarea daca o directie de prompt merita pastrata
- compararea vizuala a rezultatelor una langa alta
- decizia daca media de referinta ajuta sau incurca
- folosirea istoricului salvat pentru a continua dintr-un rezultat anterior
Acest lucru este valabil mai ales pentru munca creativa. Daca brief-ul nu este stabil, automatizarea cererii face de obicei confuzia mai rapida, nu mai mica.
Foloseste API-ul cand workflowul este repetabil
API-ul devine ruta mai buna cand inputurile si pasii urmatori sunt suficient de predictibili.
Semne bune:
- produsul tau stie deja modelul sau categoria de model de care are nevoie
- inputul utilizatorului poate fi mapat intr-un request body stabil
- un job backend poate face polling de status fara ca cineva sa urmareasca ecranul
- un webhook poate actualiza inregistrarea potrivita cand se termina un task
- aplicatia poate explica utilizarea creditelor echipei sau ownerului contului
In acel punct, folosirea Studio pentru fiecare rulare poate deveni ruta mai lenta. API-ul lasa produsul tau sa porneasca sarcina direct.
O granita practica: descoperire versus integrare
Foloseste Studio pentru descoperire.
Foloseste API-ul pentru integrare.
Descoperirea inseamna:
- "Ce model ar trebui sa folosim?"
- "Ce forma de prompt functioneaza?"
- "Media de referinta imbunatateste aceasta sarcina?"
- "Calitatea rezultatului este suficient de buna pentru acest caz de utilizare?"
Integrarea inseamna:
- "Aceasta actiune a utilizatorului ar trebui sa creeze un job de generare."
- "Acest job ar trebui reinceput idempotent."
- "Acest fisier ar trebui uploadat si atasat la o cerere de model."
- "Acest task finalizat ar trebui sa actualizeze inregistrarea din produsul nostru."
Aceasta granita impiedica API-ul sa devina o suprafata ascunsa de experimentare.
Cum ar trebui creditele sa influenteze decizia
Atat folosirea Studio, cat si folosirea API consuma din aceleasi credite ale contului Rivya.
Asta inseamna ca comportamentul creditelor ar trebui sa fie parte din designul produsului, nu o idee adaugata la final.
Foloseste mai intai Studio cand echipa inca trebuie sa invete forma costului. Foloseste API-ul cand sarcina este suficient de stabila incat produsul poate explica momentul in care creditele pot fi rezervate sau consumate.
Pentru regulile publice curente, citeste Credite API. Daca un workflow este prea scump ca sa fie explicat ownerului contului, inca nu este pregatit pentru automatizare prin API.
Unde fisierele schimba alegerea
Media de referinta este adesea locul unde o integrare devine mai serioasa.
In Studio, o persoana poate uploada, inspecta, reincerca si decide daca fisierul este suficient de bun. In API, produsul tau trebuie sa gestioneze intentionat calea fisierului prin Files API.
Foloseste Studio cand:
- imaginea, videoul sau audio-ul de referinta inca are nevoie de curatare umana
- echipa nu este sigura care referinta ar trebui sa ghideze modelul
- regulile de fisier nu sunt inca clare pentru utilizator
Foloseste API-ul cand:
- aplicatia poate colecta fisierul in siguranta
- cerintele de referinta ale modelului sunt cunoscute
- fisierul poate fi uploadat inainte de generare sau de cererea de chat
- erorile pot fi afisate in propriul produs fara sa ascunda ce s-a intamplat
Files API este o punte utila, dar nu elimina nevoia de a proiecta experienta fisierelor.
Unde chatul schimba alegerea
Chatul poate apartine de oricare parte.
Foloseste Rivya Chat direct cand o persoana exploreaza, scrie, revizuieste sau decide.
Foloseste Chat API cand tura de chat trebuie sa traiasca in propriul produs sau workflow de server. Asta poate include ture non-streaming, streaming SSE optional, sesiuni create prin API si atasamente de fisiere acceptate.
Intrebarea cheie este unde ar trebui sa traiasca conversatia. Daca discutia face parte din munca Rivya, foloseste Rivya. Daca discutia face parte din experienta produsului tau, foloseste API-ul.
Cand webhookurile sunt un semnal
Daca workflowul tau are nevoie de API Webhooks, probabil a trecut de etapa manuala Studio.
Webhookurile sunt utile cand alt sistem trebuie sa raspunda la taskuri de generare finalizate:
- marcheaza un material ca gata
- notifica un utilizator
- muta mai departe un pas de revizuire
- muta un task esuat in suport sau logica de retry
Aceasta este munca de integrare. Studio poate fi inca util pentru testarea rutei de model, dar bucla de productie apartine in API.
Un tipar sigur de migrare
Nu muta un workflow intreg in API dintr-o data.
Foloseste aceasta secventa:
- testeaza manual sarcina in Studio
- noteaza modelul stabil, forma promptului, fisierele de input si rezultatul asteptat
- citeste Modele API si referinta modelului
- trimite o generare prin Pornire rapida Rivya API
- adauga Files API doar daca modelul cere media de referinta
- adauga Webhooks doar dupa ce pollingul functioneaza
- adauga Chat API doar daca produsul are nevoie de ture de chat in afara Studio
Fiecare pas ar trebui sa faca workflowul mai usor de operat, nu doar mai automatizat.
Cand sa ramai in Studio
Ramai in Studio cand sarcina inca are nevoie de:
- revizuire subiectiva
- modelarea promptului
- comparatie vizuala
- explorarea modelelor
- istoric creativ salvat
- o persoana care decide daca urmatorul pas este imagine, video, audio sau chat
Aceasta nu este o slabiciune. Studio este proiectat pentru acea etapa.
Cand sa treci la API
Treci la API cand:
- aceeasi sarcina se repeta des
- inputul poate fi structurat
- modelul este cunoscut
- aplicatia trebuie sa creeze taskuri din propria UI
- statusul, erorile si creditele pot fi gestionate clar
- pollingul sau webhookurile se potrivesc backendului produsului
API-ul este cel mai puternic cand transforma un workflow Rivya deja inteles intr-o actiune de produs fiabila.
Urmatorul pas in Rivya
- Foloseste Developers pentru a previzualiza suprafata API.
- Citeste Pornire rapida Rivya API inainte sa scrii cod de productie.
- Citeste Autentificare API inainte sa stochezi o cheie API.
- Citeste Cum sa construiesti un workflow AI multimodal cu Rivya API daca urmatoarea intrebare este cum sa conectezi modele, fisiere, chat si webhookuri.
- Foloseste Mutarea muncii intre Rivya Chat, Image, Video si Audio daca proiectul inca apartine muncii Studio conduse de oameni.
