Про альтернативні методи зворотнього зв’язку в блозі
Минулого місяця я опублікував дві статті, в яких говорилося про використання cURL для обробки переспрямувань, які неминуче можуть статися під час роботи з певними URL-адресами.
Зокрема, я говорю про:
- Пошук місця призначення перенаправлення за допомогою PHP
- Використання cURL для визначення того, чи є вказаний URL дійсною сторінкою
І хоча другий є більш предметом цієї публікації, я хотів посилатися на обидва, оскільки вони пов’язані.
Раніше цього місяця я трохи писав про те, як змінилася мета ведення блогу. Можливо, краще було б говорити про мотивацію, а не про мету, але я відволікаюся.
У цій публікації я трохи розповім про коментарі та відгуки. І оскільки я закрив коментарі, один із способів спілкування зі мною щодо певних дописів – через Twitter.
Приклад:
І це мені подобається, тому що це:
- чітке, стисле запитання,
- воно спрямоване на мене (з можливістю втручання інших),
- і це може підтримувати розмову на тему, не перетворюючись на щось інше в коментарях.
Крім того, запитання Ксавера є хорошим, оскільки воно показує, де моєму вмісту може бути не вистачає, і дає мені можливість написати доповнення або роз’яснення до такого допису 🙂.
Справа в тому, що відповідь на це конкретне запитання може бути не такою довгою, як ведуча, але я завжди хочу надати достатньо контексту, перш ніж давати відповідь.
Відгуки в блозі та обґрунтування дизайнерських рішень
З огляду на це, коротка відповідь полягає в тому, що перевірка коду стану результату відповідної URL-адреси є хорошим способом перевірити, чи можна досягти зазначеної URL-адреси.
Тобто 200 буквально є кодом стану для OK.
Однак це не завжди означає, що URL-адреса, на яку він потрапляє першою, є кінцевим пунктом призначення, на який ви потрапите.
Зрештою, мета подвійна:
- Переконайтеся, що кінцевий пункт призначення повертає 200,
- Визначте кінцевий пункт призначення вказаної URL-адреси.
І другий момент важливий, тому що дуже багато сайтів, таких як Twitter, використовують перенаправлення як частину своїх аналітичних служб, щоб відстежувати кліки та хтозна-що-ще, коли ми переглядаємо веб-сторінки після виходу з їхнього сервісу.
Крім того, бувають випадки, коли нам може бути надано URL-адресу, скажімо, для посилання на асортимент у магазині, де цільова URL-адреса відрізняється від вихідної URL-адреси, яку ми надали.
Я відчув це на власному досвіді в проекті, над яким я працюю, що є основною мотивацією цієї оригінальної публікації.
Отже, перевірка статусів HTTP є хорошою перевіркою, але якщо ви хочете визначити, чи дійсний кінцевий пункт призначення переспрямування, це займе трохи більше.
Звичайно, все залежить від контексту того, над чим ви працюєте, чи не так? Для деяких відмінно підходить перевірка кодів стану. Для інших може знадобитися трохи більше.