Nuestra API ASP.Net Core, implementada en IIS en Windows 2019, llega y toca a Shippo con más de 2500 solicitudes por hora con números de seguimiento, que tuvieron un problema el jueves por la tarde. Nuestras llamadas API son iniciadas por los servicios de middleware de 5 clientes, que funcionan cada hora las 24 horas, los 7 días de la semana. Nuestras solicitudes de Shippo han devuelto 404, aunque Shippo resolvió el problema y puedo conectarme a través de Postman.
No soy administrador de servidores, pero tengo el conocimiento suficiente para haber probado lo siguiente: detuve y luego inicié IIS después de un retraso de 10 segundos. Reinicié la máquina. Desconectó el sitio web de API durante 90 minutos. Se vació la caché de DNS en el servidor IIS y se volvió a implementar una versión ligeramente modificada de webapi. Y, por supuesto, es un fin de semana festivo y nuestro proveedor de TI administrado no me ha respondido. ¿Qué debo intentar a continuación mientras espero?
Respuesta1
Actualización: Definitivamente estuvo relacionado con la interrupción de Shippo, pero fue un problema de codificación. Nuestro código heredado funcionó y tenía este aspecto:
UriBuilder uribuilder = new UriBuilder(settings.url_base);
uribuilder.Path += "/tracks/";
La URL que se estaba creando hacía referencia explícita al puerto 443 (https://api.goshippo.com:443)/, en lugar de la llanurahttps://api.goshippo.com/url, y no me di cuenta de eso en la depuración hasta que decidí escribir una aplicación para consultar Shippo fuera de nuestra API. Aparentemente, Shippo realizó un cambio de configuración que ya no permitía que las URL hicieran referencia al puerto 443 directamente (O cambió su puerto), en el momento en que resolvieron su problema. Una vez que configuré la URL correctamente, funcionó. Gracias, Appleoddity y Keith Langmead por su ayuda.