El automatizado, Sin código Pila de datos
Aprende cómo Astera Data Stack puede simplificar y agilizar la gestión de datos de su empresa.
6 errores de API que ocurren con frecuencia y cómo evitar que sucedan
Las API son una parte cada vez más importante de la economía del siglo XXI y de nuestra vida cotidiana. Grandes empresas como Stripe y Amazon se construyeron sobre excelentes plataformas de desarrollo. Incluso las herramientas "analógicas", como los sistemas telefónicos de oficina, están expuestas a las API. Los productos VoIP cada vez más avanzados se integran sistemas telefónicos para pequeñas empresas con software como Google Workspace. Esto abre nuevas y poderosas experiencias para empleados y clientes por igual. Pero las API no están por encima de los errores. Ya sea que sea un desarrollador de proyectos aficionado o un millonario Producto basado en SaaS usuario, encontrará que los fallos son inevitables.
¿Qué es un error/falla de API?
An Error de API se produce cuando un servidor no puede localizar el recurso solicitado del proveedor de API. En tales casos, se devuelve un mensaje de error numérico para ayudar a identificar el error específico. Las causas comunes de errores de API incluyen problemas en el punto final, parámetros incorrectos o problemas con la clave API durante la llamada de solicitud. Resolver estos errores es crucial para una comunicación fluida entre aplicaciones y garantizar una recuperación exitosa de datos del proveedor de API.
6 errores comunes de API
Algunos errores comunes de API son:
- Errores HTTP/HTTPS.
- Errores de API inútiles.
- Confusión de métodos.
- Faltan encabezados de tipo de contenido/aceptar.
- Errores de autorización.
- Errores de formato de datos.
1. Errores HTTP/HTTPS
Uno de los errores de API más comunes ocurre cuando hay confusión entre los protocolos http:// y https:// en las URL.
Para los desarrolladores, el problema es que algunas API solo admiten el protocolo HTTP, mientras que otras son compatibles con HTTPS. Algunos admiten diferentes estándares en diferentes puntos finales en el mismo producto centrado en el cliente.
Esto puede volverse aún más confuso cuando los desarrolladores unen varias API. Si son desarrolladores internos que crean soluciones "DIY" para comunicaciones comerciales asincrónicas con equipos remotos. Los desarrolladores deben dedicar tiempo a ubicar el punto final que está causando el problema y luego crear una solución alternativa para que las dos API restantes se comuniquen entre sí.
Si usted es un Proveedor de API, puede evitar este error implementando estrategias específicas de HTTPS. Por ejemplo, puede hacer que su API redirija automáticamente las solicitudes HTTP a las solicitudes HTTPS a medida que ingresan.
2. Mensajes de error de API inútiles
Para sus usuarios, la calidad de sus mensajes de error puede ser la diferencia entre un breve contratiempo y una hora dedicada a arrancarse los pelos, lo que ayuda a reduciendo la rotación de clientes.
HTTP proporciona más de 70 códigos de estado http, pero como mínimo, solo necesita implementar los más comunes con los que los desarrolladores están acostumbrados a trabajar. Ejemplos de ellos incluyen:
200 OK
¡Todo bien! Solo tenga cuidado de proporcionar este código de estado solo si todo realmente is ESTÁ BIEN. Se sabe que la API Graph de Facebook proporciona un código 200 cada vez que devuelve con éxito algún resultado, incluso si ese resultado contiene un código de error.
400 Bad Request
Esto casi siempre se debe a un error tipográfico en la entrada de su usuario. ¡Pero eso no significa que estés fuera de peligro! Asegúrese de que su mensaje de error proporcione algunos detalles sobre la entrada defectuosa para que el usuario pueda solucionarlo rápidamente.
401 no autorizado
Este estado significa que la entrada está bien, pero a la solicitud de los usuarios le falta un código de autorización. No debe confundirse con…
403 Prohibida
Esto significa que el código de autorización se reconoce como válido pero el usuario no tiene permiso. Por ejemplo, un usuario podría estar intentando acceder a algo que solo está disponible para los administradores, un problema de seguridad cada vez mayor con el personal remoto.
404 No se ha encontrado
La solicitud del usuario es válida, pero el punto final o el recurso que solicita no existe. Esto puede deberse a que el archivo se eliminó desde entonces, pero asegúrese de que no se deba a un error HTTP/HTTPS.
429 Demasiadas solicitudes
Esto ocurre cuando el mismo usuario intenta llamar a la API demasiadas veces en rápida sucesión. Después de una serie de ataques DDoS de alto perfil durante la última década, los servicios web vigilan de cerca quién accede a su servidor y con qué frecuencia.
Esta limitación de velocidad es similar a lo que encontraría en cualquier dominio u otros sitios grandes. Los proveedores de alojamiento web como Cloudflare manejan la protección DDoS para dominios alojados en sus servidores. Para las API, estas protecciones deben estar integradas.
Errores de API 5xx
Los códigos de estado que comienzan con 5 son todos errores del servidor, posiblemente de su parte. Si ese es el caso, asegúrese de que sus mensajes de error brinden ayuda o tranquilidad al usuario. Esto podría ser información de contacto o una página con información de tiempo de actividad/tiempo de inactividad en vivo.
Los proveedores de API pueden evitar mensajes de error incorrectos con solo un poco de personalización y manejo de errores. Vaya más allá del código de error y use mensajes claros y breves que se vinculen a la documentación.
Los proveedores de software deberían haber creado un perfil de consumidor objetivo de los desarrolladores que utilizarán su API. Los mensajes de error pueden y deben adaptarse a los tipos de tareas digitales que intentarán realizar.
Eche un vistazo a este mensaje de error de Twilio, cuya API permite a los desarrolladores realizar una llamada VoIP.
"`
{
“código”: 21211,
“message”: “El número 'Para' 5551234567 no es un número de teléfono válido.”,
“más_info”: “https://www.twilio.com/docs/errors/21211”,
“estado”: 400
}
"`
Más allá del estado estándar 400, hay un código de error personalizado "21211" en la parte superior. El mensaje incluso se refiere al número de teléfono virtual específico que está causando el problema. Remite al usuario a la página en su documentación donde discuten el problema 21211.
Los mensajes de error incorrectos pueden ser un gran obstáculo para los desarrolladores que intentan integrar una API en su empresa impulsada por el producto. Un proceso de integración sencillo es fundamental para el éxito de una API. Una de las primeras cosas que muchas personas escuchan sobre Stripe es lo fácil que es pegar unas pocas líneas de código y hacer que los pagos se muevan. Los buenos mensajes de error, entonces, no solo son importantes para la funcionalidad, también son un gran activo de marketing para su API.
3. Mezclas de métodos
Las API y sus usuarios pueden encontrar errores cuando confunden sus métodos de solicitud. Si el usuario envía una solicitud POST que se redirige y se devuelve como una solicitud GET, esto podría causar un error frustrante que no es su culpa.
Otra causa de errores de método es la documentación poco clara. Esto puede suceder cuando una sección de su documentación no explica qué métodos se requieren o usa el verbo incorrecto por completo. (Cuidado con el uso de la palabra "obtener" y OBTENER indistintamente. Asegúrese de que el formato de sus documentos sea claro y ahórrese un correo electrónico de atención al cliente).
4. Faltan encabezados de tipo de contenido/aceptar
La mayoría de las llamadas a la API tienen al menos dos datos de encabezado: Tipo de contenido y Aceptar. Estos encabezados ayudan a dos partes, como dos API, a negociar qué tipo de datos se envían y qué tipos se aceptarán a cambio. Como cualquier negociación, estas pueden romperse.
Algunas API aceptarán solicitudes que no tengan estos encabezados si no hay motivo para ser tan estrictos. Cada línea de código introduce posibles errores en el software, por lo que los proveedores de PBX en la nube a menudo no especifican un requisito de encabezado si no es necesario. Pero en las API comerciales con problemas de seguridad, los desarrolladores solicitarán encabezados específicos de tipo de contenido y aceptación. Esto les permite controlar estrictamente lo que se permite en su sistema y lo que se permite pasar.
Content-Type le dice a la API el formato de la fecha que estás enviando, y Accept le dice a la API qué devolver. Es posible que las API solo requieran que tenga algo en los encabezados, algunos aceptarán tipos específicos y rechazarán otros.
Esta información debe especificarse en la documentación donde no es un riesgo de seguridad hacerlo, pero ciertas herramientas de desarrollo pueden hacer tropezar a los usuarios. Considere curl, que incluye automáticamente el encabezado Aceptar predeterminado en las solicitudes. Los proveedores de API pueden anticipar estas peculiaridades de las herramientas, modificando la solicitud o enviando un mensaje de error específico.
5. Errores de autorización
Este es un error de API común y, a menudo, muy simple. Las API que utilizan el protocolo de seguridad OAuth 2 requieren una pieza adicional de datos de encabezado para procesar las solicitudes. Este es el encabezado de "autorización", que contiene la clave privada requerida para que la API procese la solicitud.
Es un error común enviar un encabezado de "autenticación" en su lugar. Esto se debe a que los desarrolladores y la documentación a menudo hablan de autenticación y autorización de manera intercambiable. Pero incluso si el encabezado está correctamente etiquetado como "autorización", los errores de formato confusos pueden hacer tropezar a la gente.
Asegúrese de que las solicitudes de la API de OAuth 2 tengan el mismo formato, con el indicador "Portador" antes de la clave privada:
"`
Autorización: Portador {your_api_key_here}
"`
Los pares de nombre de usuario y contraseña deben formatearse como "nombre de usuario: contraseña". Pero incluso si la solicitud de API no requiere una contraseña, es posible que los usuarios deban agregar dos puntos al final. Los proveedores de API podrían agregar los dos puntos ellos mismos o dejar claro en la documentación exactamente cuál es el formato.
6. Errores de formato de datos
Incluso si el usuario está haciendo todo bien, API todavía puede escupir datos en el formato incorrecto. Si la API brinda a los usuarios sus datos en HTML en lugar del JSON que pensaron que habían pedido, esto podría causar un bloqueo total. Peor aún, su desarrollo de software podría aceptar felizmente los datos y procesarlos de una manera que no se espera.
Si el desarrollador intenta unir servicios para medir la tasa de conversión de los sitios de comercio electrónico, el equipo de marketing no verá el código. Podrían pasar días analizando datos defectuosos antes de que alguien se dé cuenta de que algo no está bien.
Hemos mencionado métodos de solicitud predeterminados en GET debido a una redirección. Pero con mayor frecuencia, este error ocurre cuando el usuario no ha especificado correctamente el encabezado Aceptar, si es que lo ha hecho. Esto podría dar a los proveedores una razón para ser más estrictos con respecto a los tipos de contenido que aceptan, incluso si no es un riesgo para la seguridad.
Los proveedores de API también deben verificar los tipos de respuestas que pueden recibir por defecto o por error. Si su API no tiene motivos para procesar HTML, debe rechazar ese tipo de contenido. Esto evita problemas con los que podría encontrarse con herramientas comunes. Por ejemplo, cada vez que Nginx obtiene un tiempo de espera de solicitud, puede generar un error de HTML que su API no tiene idea de cómo procesar.
Prevención de errores explicada
La prevención de muchos de estos errores comunes se reduce a pruebas exhaustivas. También es una buena idea controlar estrictamente qué datos aceptará su API una vez que esté disponible. Además, los proveedores de API deberían dar prioridad a la excelente documentación de la API y los mensajes de error.
Esto ayudará a los usuarios a resolver los problemas por sí mismos, pero si se trata de un software para atencion al cliente, te ayudará a resolver el problema más rápido. Una vez que haya identificado esa falla, es hora de ver si puede mejorar sus documentos o incluso abstraer todo el problema para que no vuelva a suceder.
