Търся съвет за „най-добри практики“ относно гарантирането, че никакви входящи съобщения не се губят. Особено съм загрижен за прекъсването на нашия HTTP слушател, независимо дали се дължи на планирани или непланирани събития, както и възможността проблеми с маршрутизирането извън нашия контрол да попречат на Twilio дори да достигне до нашия сървър.
Екранът App Monitor на сайта на Twilio съдържа подробности за всички входящи съобщения, които не успяха да бъдат доставени до URL адреса на заявката, но освен ако не съм го пропуснал, не виждам никакъв достъп до него чрез API.
Мислех да изпратя фиктивно съобщение, указващо URL адреса за обратно извикване, като средство за потвърждение, че Twilio има достъп до нашия сайт, но дори при едно съобщение всяка минута, пак може да пропусне кратки прекъсвания поради преходни проблеми с маршрутизирането. Резервният URL адрес също не отговаря на моите притеснения, тъй като може да бъде засегнат от същите проблеми, които засягат URL адреса на основната заявка.
Единственият начин, който виждам да направя това, е периодично да използвам ресурса за списък със съобщения, за да сравнявам с база данни от получени съобщения на HTTP слушателя, но не ми харесва фактът, че е ограничен до детайлност на филтриране от 24 часа. В идеалния случай бих искал да стартирам тази процедура за „кръстосана проверка“ на всеки 5 до 10 минути или така и да посоча диапазон от времеви отпечатъци, за да минимизирам количеството ненужен достъп до процесора / базата данни.
Някой измислил ли е някакви умни решения за това?
