„Érvénytelen hivatkozás” hiba az API-ban: URL-ellenőrzés a rendelés létrehozása előtt

Mit jelent az „érvénytelen hivatkozás” hiba az API-ban

Az „érvénytelen hivatkozás” hiba azt jelenti, hogy az API nem tudta elfogadni az URL-t a rendelés célmezőjében. Ez nem mindig elírás a címben. A szolgáltatás elutasíthatja a hivatkozást nem megfelelő formátum, oldaltípus, átirányítás, hozzáférési korlátozások, kódolás vagy a platform és a szolgáltatás közötti eltérés miatt.

Az ellenőrzés általában a rendelés létrehozása előtt történik. Az API megkapja az URL-t, meghatározza a domaint és az elérési utat, és megpróbálja felismerni az objektumot: csatorna, videó, élő közvetítés, bejegyzés vagy profil. Ha valamelyik lépés nem sikerül, a rendelés nem jön létre. Az általános hibaüzenet önmagában nem mutatja meg az okot — meg kell nézni az URL-t, a szolgáltatási paramétereket és az API teljes válaszát.

Hasonlítsa össze a hibaüzenetet az API válaszával

A különböző API-k megfogalmazása és válaszstruktúrája eltér. Néha a szolgáltatás csak egy üzenetet ad vissza, néha hozzáad egy kódot, egy mezőnevet vagy egy kérésazonosítót. A teljes válasz hasznosabb, mint a HTTP-státusz: még a kérés sikeres kézbesítése esetén is elutasíthatja az API magát a rendelést üzleti ellenőrzés szintjén.

Például egy tipikus válasz így nézhet ki: {"error":"invalid_link","message":"Invalid target URL","field":"link"}. Itt érdemes pontosan a link mező értékét ellenőrizni. A {"error":"target_not_supported"} változat inkább nem a hibás címre, hanem a nem támogatott objektumtípusra utal. A mezőnevek és kódok a konkrét dokumentációtól függenek.

Őrizze meg a válasz státuszát, a válasz törzsét, a szolgáltatás azonosítóját és a request_id-t, ha az API visszaadja. Ne adjon a jegyhez hozzáférési tokent, cookie-t, kérésaláírásokat és a hivatkozás privát paramétereit.

Ellenőrizze az URL formátumát és a kérésmező értékét

Egy böngészőben működő hivatkozás nem biztos, hogy átmegy a gépi ellenőrzésen. A mezőbe néha csak a videó azonosítója, domain nélküli felhasználónév, egy üzenetből származó szöveg vagy rövidített cím kerül. A hiba akkor is fellép, ha az URL nem karakterláncként, hanem beágyazott objektumként vagy tömbként van átadva.

• Adja át a teljes nyilvános URL-t a https:// protokollal együtt.
• Ellenőrizze a domaint: a kiválasztott szolgáltatás platformjához kell tartoznia.
• Távolítsa el a széleken lévő szóközöket, sortöréseket, emojikat és a hivatkozás utáni szöveget.
• Vesse össze a mező nevét az API dokumentációjával: link, url, target vagy más.
• Győződjön meg róla, hogy a kérésben karakterlánc-érték van átadva, nem pedig egy URL-t tartalmazó objektum.

A cím kézi beillesztése kényelmes, de van egy hátránya: könnyen bekerül a karakterláncba egy láthatatlan karakter vagy a bejegyzés feliratának egy részlete. Küldés előtt tisztítsa meg az értéket, de szükségtelenül ne módosítsa magát az elérési utat és a paramétereket.

Fejtse ki a rövid hivatkozásokat, és távolítsa el a felesleges átirányításokat

A rövidített címek és a „Megosztás” gombból származó hivatkozások gyakran egy vagy több átirányításon mennek keresztül. A böngésző automatikusan megnyitja őket, de a promóciós szolgáltatás API-ja nem biztos, hogy követi az átirányításokat, blokkolhatja azokat, vagy egy köztes bejelentkezési oldalt kap.

A rendeléshez jobb a kanonikus címet használni: azt, amely a kívánt oldal teljes betöltése után látható a címsorban. A kampánycímkék és a megtekintési idő paraméterei nem mindig zavaróak, de a paraméterek az oldal más megjelenítéséhez vezethetnek, vagy befolyásolhatják az objektum felismerését.

A kanonikus URL-nek van egy hátránya: néha külön kell beszerezni, különösen akkor, ha a hivatkozást mobilalkalmazásból másolták. Viszont egy ilyen címet könnyebb manuálisan ellenőrizni és összevetni a szolgáltatás szabályaival.

Válasszon olyan objektumra mutató hivatkozást, amelyet a szolgáltatás elfogad

A szolgáltatás csak egyetlen céltípust fogadhat el. A csatornára vonatkozó rendelés nem fogadja el az élő adás bejegyzésére mutató hivatkozást, a videó megtekintéseire vonatkozó szolgáltatás pedig nem fogadja el a szerzői profilt. Kívülről mindkét URL helyes, de az API összeveti a cím szerkezetét a szolgáltatás rendeltetésével, és elutasítja a nem megfelelő objektumot.

Ellenőrizze a szolgáltatáskatalógust: a platformot, a kategóriát, az engedélyezett target_type-ot és a korlátozásokat. Ha az API külön céltípus-paramétert igényel, annak meg kell egyeznie az URL-lel. Ne cserélje le a tartalom címét keresésre, hashtagre, válogatásra, főoldalra vagy a szerzői fiókra mutató hivatkozásra.

• Csatorna promóciójához a csatorna oldalát adja át.
• Megtekintésekhez egy konkrét videóra vagy bejegyzésre mutató hivatkozást használjon.
• Aktív élő adáshoz az adás URL-jét adja át, ha a szolgáltatás támogatja a live formátumot.
• Reakciókhoz és a bejegyzéssel kapcsolatos egyéb műveletekhez közvetlen hivatkozást használjon a bejegyzésre.

Ellenőrizze az adatvédelmet, a korhatár-szűrőket és a bejelentkezési követelményt

Az API nem csak az URL formáját ellenőrzi, hanem a cél elérhetőségét is. A tartalom megnyílhat a csatorna tulajdonosánál, mert a böngészője be van jelentkezve, de elérhetetlen lehet egy külső ellenőrző szerver számára. Ebben az esetben a szolgáltatás gyakran általános hibát ad vissza az érvénytelen hivatkozásról.

• Ellenőrizze, hogy nincs-e lezárva a profil, a csatorna, a bejegyzés vagy maga az élő adás.
• Győződjön meg róla, hogy a videó nincs törölve, piszkozatba helyezve vagy más bejegyzéssel helyettesítve.
• Ellenőrizze a korhatár-korlátozást: szükség lehet életkor megerősítésére vagy bejelentkezésre.
• Kapcsolja ki a csak előfizetők, tagok vagy jóváhagyott nézők számára elérhető hozzáférési módot, ha be van kapcsolva.
• Győződjön meg róla, hogy az oldal nem mutat bejelentkezési űrlapot, tartalomfigyelmeztetést vagy technikai helyettesítő oldalt.

Nyissa meg a hivatkozást privát ablakban, bejelentkezés nélkül. Ha a céloldal helyett bejelentkezési kérés látható, módosítsa a hozzáférési beállításokat, vagy válasszon olyan szolgáltatást, amely engedélyezi ezt a céltípust, ha van ilyen. A privát ablakban végzett ellenőrzés hátránya, hogy nem mindig deríti fel a regionális és hálózati korlátozásokat.

Vegye figyelembe a regionális, mobil és beágyazott címeket

Egy objektumnak lehet asztali, mobil, lokalizált és beágyazott URL-je. Az alkalmazásból vagy webview-ból származó cím néha technikai szegmenseket tartalmaz, amelyeket az API nem ismer fel. A lokalizált oldal másképp is megnyílhat az ellenőrző szerver számára.

Nyissa meg a másolt hivatkozást egy normál böngészőben, és várja meg a teljes betöltést. A kéréshez használja a címsorban látható nyilvános webcímet. Ha a tartalom régió szerint korlátozott, távolítsa el a korlátozást, ha ezt a platform beállításai engedélyezik, vagy ne küldjön ilyen célt olyan szolgáltatásnak, amelynek nyilvános hozzáférésre van szüksége.

A bejelentkezés és köztes képernyők nélküli nyilvános webes hivatkozás a legmegbízhatóbb lehetőség az API-ellenőrzéshez.

Zárja ki az URL sérülését a kérés küldésekor

A hivatkozás a küldés előtt helyes lehet, de megváltozhat a JSON szerializálása, a query-paraméterek összeállítása, a form-data küldése vagy az újrakódolás során. Különösen érzékenyek az &, ?, # és % karakterek. Például az URL-ben lévő ampersand a kérés paramétereinek elválasztójává válhat, ha a cím a szükséges kódolás nélkül kerül átadásra.

• Hasonlítsa össze az eredeti URL-t a tényleges HTTP-kérésben szereplő értékkel.
• Ellenőrizze a kérés törzsét az ügyfél naplóiban, proxyban vagy fejlesztői eszközökben.
• JSON esetén használjon szabványos szerializálást, ne kézi karakterlánc-összeállítást.
• Ne kódolja kétszer az URL-t, ha a könyvtár ezt automatikusan megteszi.
• Ellenőrizze a cirill betűk kezelését az elérési útban és a cím paramétereiben.

A naplók segítenek gyorsan megtalálni az eltérést, de van egy hátrányuk: API-kulcsok, tokenek és személyes adatok kerülhetnek beléjük. Maszkolja az érzékeny értékeket a naplók írása és továbbítása előtt.

Vesse össze a platformot, a szolgáltatás azonosítóját és a rendelési paramétereket

Egyes API-k először a szolgáltatást, majd a domaint és a hivatkozás típusát ellenőrzik. Egy másik platform URL-je, egy elavult service_id vagy egy helytelen target_type ugyanahhoz az „érvénytelen hivatkozás” hibához vezethet. Ebben az esetben hiába változtatja meg magát a címet, amíg a rendelési paraméterek nincsenek kijavítva.

Frissítse a szolgáltatáskatalógust az API-metóduson keresztül, ha van ilyen. Egy régi listát tartalmazó gyorsítótár tárolhat egy letiltott szolgáltatást vagy annak korábbi követelményeit. A katalógus gyakori frissítésének hátránya: növeli a kérések számát, és ütközhet a gyakorisági korláttal. Használjon korlátozott élettartamú gyorsítótárat, és frissítse azt az érvényesítési hibák után.

Ellenőrizze a hivatkozást sorrendben az újraküldés előtt

1. Másolja ki a teljes URL-t szöveg, szóközök és rejtett karakterek nélkül.
2. Nyissa meg privát ablakban, bejelentkezés nélkül.
3. Ellenőrizze, hogy az oldal nincs lezárva, törölve, és nem igényel bejelentkezést.
4. Győződjön meg róla, hogy nincs korhatár-, előfizetés- vagy regionális korlátozás.
5. Fejtse ki a rövid hivatkozást a végső nyilvános címig.
6. Hasonlítsa össze az URL-ben lévő objektumot a szolgáltatással: csatorna, videó, élő adás vagy bejegyzés.
7. Vesse össze a platformot, a service_id-t és a target_type-ot az aktuális szolgáltatáskatalógussal.
8. Ellenőrizze a tényleges HTTP-kérés törzsét és az URL kódolását.
9. Őrizze meg az API teljes válaszát és a kérésazonosítót tokenek és privát adatok nélkül.

Ha ezen ellenőrzések után a hiba továbbra is fennáll, küldje a támogatásnak a hivatkozást megtisztított formában, a szolgáltatás azonosítóját, a kérés idejét, a HTTP-státuszt és az API válaszának teljes szövegét. Ez lehetővé teszi az URL-probléma megkülönböztetését egy adott szolgáltatás korlátozásától vagy a szolgáltatás oldalán történő ellenőrzési hibától.