Перевірка зворотних посилань повернула нічого: таблиця помилок

Правило, що охоплює більшість випадків

Повторюйте спроби при мережевих збоях. Ніколи не повторюйте спроби для 401 чи 402. Перший тип виправляється за секунди; другий потребує втручання людини, а інтенсивні повторні спроби лише заповнюють ваші логи.

Кожна відповідь JSON містить поле ok, а аутентифіковані відповіді додають _credits з вартістю виклику та залишком балансу. Перевіряйте ok у тілі відповіді, навіть якщо HTTP-статус виглядає коректно.

Часи повторних спроб нижче — це наша інженерна порада, а не задокументовані ліміти. У документації API, якою ми володіємо, не опубліковано ліміт частоти запитів, тому встановіть власну межу та тримайте її помірною.

Чому 401 і 402 ніколи не повторюються

401 — це проблема ключа, а 402 — проблема балансу. Жоден із цих статусів не зникає між двома спробами з інтервалом у секунду, тому повторна спроба лише додає шум у логи і нічого більше.

Очікування також не виправляє 402. Баланс залишається незмінним, доки хтось не поповнить його через особистий кабінет, тому єдина корисна реакція — чітке повідомлення та сповіщення тому, хто відповідає за бюджет.

401 вимагає уваги до заголовка або параметра ключа, а також перевірки того, чи не було замінено ключ. Повторні спроби з тим самим неправильним ключем нічого не доводять.

Неправильний ключ і порожній баланс також виглядають по-різному у вашій панелі керування. Налаштуйте окремі сповіщення, щоб людину, яка поповнює баланс, не будили через одруківку ключа, а того, хто змінює ключі, не викликали через баланс.

Мережеві збої та експоненційне сповільнення

Тайм-аут або скидання з'єднання можуть виправитися самі, тому це єдині випадки, варті ще однієї спроби. Чекайте 1, 2, 4 і потім 8 секунд, додайте невеликий джитер (випадкове відхилення часу) і припиніть після четвертої спроби.

Ці часи — наша порада, а не задокументований ліміт. Тримайте власну межу, логуйте кожну повторну спробу та сповіщайте, коли кількість повторних спроб зростає, оскільки зростаючий рівень повторних спроб зазвичай є першим знаком проблеми на стороні постачальника послуг.

Зробьте тайм-аут на вашому боці явним, у вигляді іменованої константи. Неявний значення за замовчуванням, яке змінюється при оновленні бібліотеки, є поширеною причиною того, що нічна задача починає падати лише на одній машині.

Спостерігайте за часом відповіді постачальника послуг, а не лише за частотою помилок. Повільна відповідь, яка ніколи не падає, все одно може блокувати ваших робітників, а цикл повторних спроб погіршує це уповільнення.

Нормалізуйте домен перед викликом

Більшість невдалих викликів починаються з поля вводу, а не в мережі. Користувачі вставляють те, що скопіювали, і ваш код має перетворити це на чистий домен, перш ніж API це побачить.

Видаліть схему та шлях

Видаліть схему, будь-який шлях і рядок запиту. Вставлена адреса статті стає своїм хостом, і тільки хост надходить на сторону постачальника послуг.

Приведіть хост до нижнього регістру теж. Зберіть очищення в одній функції, щоб одне й те саме правило застосовувалося у формі, у пакетній задачі та в тестах.

Протестуйте очищення на п'яти-шести реальних вставлених вхідних даних, включаючи один із завершальною слешем та один із рядком запиту. Ці випадки виявляють баги, які чистий приклад ніколи не покаже.

Одноразово вирішіть, що робити з www.

Оберіть одне правило для www. і застосовуйте його в одній функції, щоб один і той самий сайт ніколи не шукався під двома написами.

Запишіть правило поруч із функцією. Наступний розробник, який зіткнеться з випадковим www, тоді знайде рішення, а не друге думку.

Яке б правило ви не обрали, тримайте його в одному файлі і напишіть один тест для нього. Тест — це запис рішення, і він короткий.

Відхиляйте те, що не може бути доменом

Відмовляйте у вхідних даних із пробілами або порожніми мітками та показуйте коротке повідомлення у формі. Відхилене рядок нічого не коштує, тоді як поганий коштує невдалого виклику та збентеженого користувача.

Завершальні крапки — це дивний випадок. Видаліть одну в кінці хоста і вважайте все інше недійсним.

Показуйте відхилення поруч із полем, а не як toast, що зникає. Користувач, який бачить, що не так, виправить це з першої спроби.

Порожні результати та вік індексу

Коли хтось вводить check my backlink у вашу форму і отримує нічого, порожня відповідь не завжди є помилкою. Вона часто означає, що домен новий, занадто малий або просто ще не в індексі, і екран повинен сказати, що саме.

Абсолютно новий сайт

Сайт, запущений минулого тижня, може не мати посилальних доменів в індексі. Покажіть "ще не проіндексовано" разом із датою індексу та запропонуйте безкоштовний виклик overview як перехресну перевірку.

Не кешуйте цю порожню відповідь довго. Кількох годин цілком достатньо, і наступне оновлення може додати сайт до індексу.

Повідомте відвідувачеві, коли індекс був востаннє перебудований, звичайними словами. Дата поруч із порожньою відповіддю пояснює проміг краще, ніж довше повідомлення.

Тут достатньо короткої примітки у вашому власному інтерфейсі. Ніхто не очікує живого індексу, і пряме речення поруч із датою індексу читається як чесність.

Число, яке не збігається з іншим інструментом

Різні краулери бачать різні шматки мережі. Читайте показник DR як позицію всередині одного інструменту та вказуйте читачам на довідник DR для формули.

Коротка примітка під показником заощадить більше часу підтримки, ніж будь-яка кількість вибачень після факту.

Якщо два покази відрізняються, спочатку порівняйте кількість посилальних доменів. Формула DR проста, тому більшість розбіжностей зводиться до кількості.

Рядки, що обрізаються на 50 000

Коли список обрізається на межі, відповідь коректна для того, що дозволяє API. Позначте обрізання та посилання на примітки щодо пагінації, а не намагайтеся глибшу сторінку.

Глибші сторінки після цієї точки — це не повторна спроба. Це інший запит, і саме так цикл працює годинами.

Тримайте обрізання видимим і в експорті, щоб таблиця, відкрита через місяць, все ще показувала, що список був обмежений.

Показ кількості рядків поруч із таблицею перетворює обрізання на видимий факт. Читач, який бачить 50 000 рядків, знає, що варто поставити більш вузьке запитання.