Napaka »neveljavna povezava« v API: preverjanje URL pred ustvarjanjem naročila

Kaj pomeni napaka »neveljavna povezava« v API

Napaka »neveljavna povezava« pomeni, da API ni mogel sprejeti URL v polju cilja naročila. To ni vedno tipkarska napaka v naslovu. Storitev lahko povezavo zavrne zaradi neustrezne oblike, vrste strani, preusmeritve, omejitev dostopa, kodiranja ali neujemanja platforme s storitvijo.

Preverjanje običajno poteka pred ustvarjanjem naročila. API prejme URL, določi domeno in pot, poskusi prepoznati objekt: kanal, posnetek, prenos v živo, objavo ali profil. Če ena od stopenj ne uspe, naročilo ne bo ustvarjeno. Splošno besedilo napake samo po sebi ne pokaže vzroka — treba je pogledati URL, parametre storitve in celoten odgovor API.

Ujemite besedilo napake z odgovorom API

Različni API-ji se razlikujejo po formulaciji in strukturi odgovora. Včasih storitev vrne samo sporočilo, včasih doda kodo, ime polja ali identifikator zahteve. Celoten odgovor je bolj koristen kot status HTTP: tudi ob uspešni dostavi zahteve lahko API zavrne samo naročilo na ravni poslovnega preverjanja.

Na primer, tipičen odgovor je lahko videti takole: {"error":"invalid_link","message":"Invalid target URL","field":"link"}. Tu velja preveriti prav vrednost polja link. Različica {"error":"target_not_supported"} pogosteje kaže ne na pokvarjen naslov, ampak na nepodprto vrsto objekta. Imena polj in kod so odvisna od konkretne dokumentacije.

Shranite status odgovora, telo odgovora, identifikator storitve in request_id, če ga API vrne. V zahtevek ne dodajajte dostopnega žetona, piškotkov, podpisov zahteve in zasebnih parametrov povezave.

Preverite obliko URL in vrednost polja zahteve

Povezava, ki deluje v brskalniku, morda ne bo prestala strojnega preverjanja. V polje včasih zaide samo identifikator posnetka, vzdevek brez domene, besedilo iz sporočila ali skrajšan naslov. Napaka nastane tudi, ko URL ni poslan kot niz, ampak kot gnezden objekt ali matrika.

• Pošljite celoten javni URL skupaj s protokolom https://.
• Preverite domeno: mora pripadati platformi izbrane storitve.
• Odstranite presledke na robovih, prelome vrstic, čustvene simbole in besedilo za povezavo.
• Primerjajte ime polja z dokumentacijo API: link, url, target ali drugo.
• Prepričajte se, da je v zahtevi poslana vrednost niza in ne objekt z URL znotraj.

Ročno lepljenje naslova je priročno, ima pa slabost: v niz zlahka zaide nevidni znak ali del podpisa objave. Pred pošiljanjem očistite vrednost, vendar same poti in parametrov ne spreminjajte brez potrebe.

Razširite kratke povezave in odstranite odvečne preusmeritve

Skrajšani naslovi in povezave iz gumba »Deli« pogosto gredo skozi eno ali več preusmeritev. Brskalnik jih odpre samodejno, API storitve za promocijo pa morda ne sledi preusmeritvam, jih blokira ali prejme vmesno stran za prijavo.

Za naročilo je bolje uporabiti kanonični naslov: tistega, ki je viden v naslovni vrstici po celotnem nalaganju želene strani. Oznake kampanj in parametri časa ogleda niso vedno ovira, lahko pa parametri vodijo do drugačne predstavitve strani ali vplivajo na prepoznavo objekta.

Kanonični URL ima slabost: včasih ga je treba pridobiti posebej, zlasti po kopiranju povezave iz mobilne aplikacije. Je pa tak naslov lažje ročno preveriti in primerjati s pravili storitve.

Izberite povezavo do objekta, ki ga storitev sprejme

Storitev lahko sprejme samo eno vrsto cilja. Naročilo za kanal ne bo sprejelo povezave do posnetka prenosa v živo, storitev za oglede posnetka pa ne bo sprejela profila avtorja. Navzven sta oba URL veljavna, vendar API primerja strukturo naslova z namenom storitve in zavrne neustrezni objekt.

Preverite imenik storitev: platformo, kategorijo, dovoljeni target_type in omejitve. Če API zahteva ločen parameter vrste cilja, se mora ujemati z URL. Naslova vsebine ne zamenjujte s povezavo do iskanja, ključnika, izbora, domače strani ali avtorjevega profila.

• Za promocijo kanala pošljite stran kanala.
• Za oglede uporabite povezavo do konkretnega videoposnetka ali posnetka.
• Za aktivni prenos v živo pošljite URL prenosa, če storitev podpira live-format.
• Za odzive in druga dejanja z objavo uporabite neposredno povezavo do objave.

Preverite zasebnost, starostne filtre in zahtevo po prijavi

API ne preverja le oblike URL, ampak tudi dostopnost cilja. Vsebina se lahko odpre lastniku kanala, ker je njegov brskalnik prijavljen, zunanjemu preverjevalnemu strežniku pa je lahko nedostopna. V tem primeru storitev pogosto vrne splošno napako o neveljavni povezavi.

• Preverite, ali profil, kanal, objava ali sam prenos niso zaprti.
• Prepričajte se, da posnetek ni izbrisan, premaknjen v osnutke ali zamenjan z drugo objavo.
• Preverite starostno omejitev: lahko zahteva potrditev starosti ali prijavo v račun.
• Izklopite način dostopa samo za naročnike, udeležence ali odobrene gledalce, če je vklopljen.
• Prepričajte se, da stran ne prikazuje obrazca za prijavo, opozorila o vsebini ali tehnične nadomestne strani.

Odprite povezavo v zasebnem oknu brez prijave. Če se namesto ciljne strani prikaže zahteva za prijavo, spremenite nastavitve dostopa ali izberite storitev, ki dopušča takšno vrsto cilja, če je predvidena. Slabost preverjanja v zasebnem oknu je, da ne odkrije vedno regionalnih in omrežnih omejitev.

Upoštevajte regionalne, mobilne in vgrajene naslove

En objekt ima lahko namizni, mobilni, lokalizirani in vgrajeni URL. Naslov iz aplikacije ali webview včasih vsebuje tehnične segmente, ki jih API ne prepozna. Tudi lokalizirana stran se lahko preverjevalnemu strežniku odpre drugače.

Odprite kopirano povezavo v običajnem brskalniku in počakajte na celotno nalaganje. Za zahtevo uporabite javni spletni naslov iz naslovne vrstice. Če je vsebina omejena po regiji, odstranite omejitev, če to dopuščajo nastavitve platforme, ali takšnega cilja ne pošiljajte storitvi, ki potrebuje javni dostop.

Javna spletna povezava brez prijave in vmesnih zaslonov je najzanesljivejša možnost za preverjanje API.

Izključite poškodbo URL pri pošiljanju zahteve

Povezava je lahko pred pošiljanjem pravilna, a se spremeni pri serializaciji JSON, sestavljanju query-parametrov, pošiljanju form-data ali ponovnem kodiranju. Posebej občutljivi so znaki &, ?, # in %. Na primer, ampersand v URL lahko postane ločilo parametrov same zahteve, če je naslov poslan brez potrebnega kodiranja.

• Primerjajte izvorni URL z vrednostjo v dejanski zahtevi HTTP.
• Preverite telo zahteve v dnevnikih odjemalca, posrednika ali razvojnih orodjih.
• Za JSON uporabite standardno serializacijo in ne ročnega sestavljanja niza.
• URL ne kodirajte dvakrat, če to knjižnica počne samodejno.
• Preverite obdelavo cirilice v poti in parametrih naslova.

Dnevniki pomagajo hitro najti odstopanje, imajo pa slabost: vanje lahko zaidejo ključi API, žetoni in osebni podatki. Občutljive vrednosti maskirajte pred zapisom in prenosom dnevnikov.

Primerjajte platformo, identifikator storitve in parametre naročila

Nekateri API-ji najprej preverijo storitev, nato domeno in vrsto povezave. URL druge platforme, zastarel service_id ali napačen target_type lahko privedejo do iste napake »neveljavna povezava«. V tem primeru je spreminjanje samega naslova brezpredmetno, dokler niso popravljeni parametri naročila.

Osvežite katalog storitev prek metode API, če je predvidena. Predpomnilnik s starim seznamom lahko hrani onemogočeno storitev ali njene prejšnje zahteve. Pogosto osveževanje kataloga ima slabost: povečuje število zahtev in lahko naleti na omejitev pogostosti. Uporabite predpomnilnik z omejeno dobo shranjevanja in ga osvežite po napakah preverjanja.

Pred ponovnim pošiljanjem povezavo preverite po vrsti

1. Kopirajte celoten URL brez besedila, presledkov in skritih znakov.
2. Odprite ga v zasebnem oknu brez prijave v račun.
3. Preverite, da stran ni zaprta, izbrisana ali ne zahteva prijave.
4. Prepričajte se, da ni starostne, naročniške ali regionalne omejitve.
5. Razširite kratko povezavo do končnega javnega naslova.
6. Primerjajte objekt v URL s storitvijo: kanal, videoposnetek, prenos v živo ali objava.
7. Primerjajte platformo, service_id in target_type z aktualnim katalogom storitev.
8. Preverite dejansko telo zahteve HTTP in kodiranje URL.
9. Shranite celoten odgovor API in identifikator zahteve brez žetonov in zasebnih podatkov.

Če napaka po teh preverjanjih ostane, podpori pošljite povezavo v očiščeni obliki, identifikator storitve, čas zahteve, status HTTP in celotno besedilo odgovora API. To bo omogočilo razlikovanje med težavo z URL in omejitvijo konkretne storitve ali napako preverjanja na strani storitve.