Buzzsprout atver automatizāciju visiem plāniem — tīmekļa āķu vēl nav

Buzzsprout 9. oktobrī paplašināja savu API, lai ārējas lietotnes varētu augšupielādēt podkāsta epizodes, rediģēt transkriptus un pārvaldīt katalogu ierakstus. Par šo pašu paplašinājumu 14. oktobrī rakstīja RYM Magazine. Podkāsta veidotājs šīs darbības var iekļaut savā publicēšanas plūsmā, taču integrācija nesaņem tūlītēju paziņojumu par vēlākām izmaiņām.

Buzzsprout API aprakstā norādīts, ka piekļuve ir iekļauta visos plānos, pieprasījumus autentificē ar podkāstam piesaistītu marķieri un tīmekļa āķi pašlaik nav pieejami. API izmanto REST pieeju un JSON atbildes. Tātad automatizācija var sākt publicēšanas darbības, bet epizodes vēlāk mainītais stāvoklis tai jānoskaidro ar jaunu pieprasījumu.

Ko paplašinātais API ļauj izdarīt

Jaunā piekļuve aptver vairāk nekā epizožu saraksta nolasīšanu. Integrācija var izveidot vai atjaunināt epizodi un no savas sistēmas nosūtīt tai saturu. Tas ļauj sasaistīt sagatavotu ierakstu ar publicēšanas procesu, neveicot katru darbību manuāli Buzzsprout kontā.

Transkriptu rediģēšana ir atsevišķa iespēja: ārējs rīks var nodot labojumus pēc tam, kad teksts sagatavots citur. API paplašinājums aptver arī katalogu ierakstu pārvaldību. Šo iespēju nevajadzētu jaukt ar solījumu, ka ārējs katalogs iesniegumu apstrādās noteiktā laikā; tā lēmums paliek ārpus podkāsta veidotāja integrācijas.

Publicēšanas plūsmā ir vēl viena robeža. Iespēja nosūtīt epizodi nenozīmē, ka audio apstrāde un publiskošana vienmēr pabeidzas tajā pašā brīdī. Ja nākamais darbs ir atkarīgs no epizodes faktiskā stāvokļa, integrācijai tas jānolasa pirms turpināšanas, nevis jāsecina tikai no veiksmīgi nosūtīta pieprasījuma.

Darbību matrica: ko var automatizēt un ko nevar

Atšķirība ir starp darbībām, ko integrācija pati ierosina, un izmaiņām, par kurām tai jāuzzina vēlāk. Pirmās var iekļaut automatizētā publicēšanas ķēdē. Otrajām pašlaik vajadzīga periodiska datu pārbaude.

• Var automatizēt: epizodes izveidi un atjaunināšanu, audio nosūtīšanu, transkripta labošanu un atbalstīto katalogu ierakstu pārvaldību.
• Var automatizēt ar pārbaudi: nākamās darbības sākšanu pēc tam, kad Buzzsprout atbildē redzams vajadzīgais epizodes stāvoklis.
• Nevar automatizēt ar Buzzsprout tīmekļa āķi: tūlītēja paziņojuma saņemšanu, kad platformā vēlāk mainās epizode vai tās apstrādes stāvoklis.
• Nevar noteikt ar šo API: brīdi, kad ārējs podkāstu katalogs pabeigs paša iesnieguma apstrādi.

Šī matrica attiecas uz Buzzsprout API iespējām, nevis uz visām darbībām, ko spēj veikt citi pakalpojumi. Piemēram, transkripta labojuma nosūtīšana ir automatizējama, bet lēmums par to, vai labojums ir redakcionāli pareizs, jāpieņem pašā satura sagatavošanas plūsmā. Līdzīgi katalogu ieraksta iesniegšana un tā parādīšanās ārējā katalogā ir atšķirīgi posmi.

Kā varētu izskatīties droša publicēšanas plūsma

Vienkāršā nosacītā uzbūvē redakcijas rīks sagatavo epizodes audio, nosaukumu un aprakstu. Servera uzdevums nosūta šos datus Buzzsprout, pēc tam periodiski nolasa epizodes stāvokli un turpina plūsmu, kad redzams vajadzīgais rezultāts. Šis ir integrācijas piemērs, nevis Buzzsprout piedāvāts gatavs redakcijas process.

Marķieris šādā plūsmā glabājas servera noslēpumu glabātuvē vai aizsargātā izvietošanas vides mainīgajā. Serveris to pievieno pieprasījumam izpildes laikā; marķieri nevajag ievietot pārlūkprogrammai piegādātā kodā, jo to tad varētu nolasīt arī citi. Ja konta īpašnieks marķieri atiestata, jaunā vērtība jāievieto integrācijas glabātuvē.

Uzdevumam jāatceras arī pēdējais sekmīgi nolasītais epizodes stāvoklis. Tad nākamā atbilde ļauj atšķirt patiesu izmaiņu no atkārtotas tās pašas informācijas saņemšanas. Neizdevies pieprasījums savukārt nav jauns epizodes statuss: integrācijai tas jāapstrādā kā kļūme un jāplāno atkārtots mēģinājums, nesākot atkarīgo darbu priekšlaikus.

Periodiska pārbaude nosaka reakcijas kavējumu

Bez tīmekļa āķiem izmaiņa kļūst zināma nākamajā sekmīgajā pārbaudē. Ja integrācija nosacīti pārbauda epizodi ik pēc desmit minūtēm, tūlīt pēc iepriekšējās pārbaudes notikusi izmaiņa var palikt nepamanīta gandrīz desmit minūtes. Tas ir ilustratīvs intervāls, nevis Buzzsprout noteikts pārbaudes grafiks; pieprasījuma kļūme gaidīšanu var pagarināt.

Īsāks intervāls parasti saīsina reakcijas laiku, bet palielina pieprasījumu skaitu. Buzzsprout atbildēs paredzētās ETag un Last-Modified galvenes ļauj integrācijai pārbaudīt, vai resurss mainījies, atkārtoti nelejupielādējot nemainītu epizodes saturu. Pats pārbaudes pieprasījums tomēr joprojām tiek nosūtīts, tāpēc biežums jāpielāgo vajadzīgajam reakcijas laikam un API slodzei.

Ja pārbaude neizdodas, saprātīga integrācijas izvēle ir īslaicīgas kļūmes gadījumā nogaidīt un mēģināt vēlreiz, saglabājot pēdējo droši zināmo stāvokli. Kad nākamā sekmīgā atbilde rāda izmaiņu, plūsma var turpināties vienu reizi, nevis atkārtot jau izpildītu darbību pēc katras nolasīšanas. Tāpēc epizodes augšupielādes automatizēšana var sākties uzreiz, bet no vēlākas apstrādes atkarīgais posms sāksies tikai pēc nākamās sekmīgās pārbaudes.

Lasiet arī:

• Podigee apvieno podkāsta ķēdi — faili vairs nav jāstumj starp rīkiem
• Zapier vai Power Automate: viena darbība rēķinā nenozīmē to pašu
• Buzzsprout vai Podbean: vienkāršība sacenšas ar neierobežotu glabāšanu