Header Ads Widget

Ticker

6/recent/ticker-posts

5 áreas más de coherencia para una gran experiencia de desarrollador


 La consistencia es quizás una de las facetas más críticas de cualquier producto desarrollado. Que el producto funcione bien, utilice los mismos puntos de interacción para funciones predecibles y alinee sus objetivos de desarrollo, es clave para el éxito y la longevidad en el espacio API. No importa cuán grande o pequeña sea una API, un buen desarrollo nunca pasa de moda.

En nuestro artículo anterior , discutimos cuatro áreas generales de consistencia: Consistencia de Naming y Endpoint, Paradigma de Diseño de API, Manejo de Errores y Documentación. Si bien estos son puntos indudablemente importantes, hay aún más consideraciones cuando se busca brindar una experiencia de API universalmente consistente.

A continuación, analizamos cinco áreas más de coherencia para sus diseños de API. Estos conceptos generalmente se aplican independientemente del tipo de API que desarrolle y del servicio que brinde.

1. Soporte y comentarios

Tener un canal claro de apoyo y aceptación de los comentarios de los desarrolladores, y fomentar su uso.

En última instancia, el proveedor de API está separado del usuario desarrollador. El desarrollador consume la API, sin embargo, elige implementarla , mientras que el proveedor solo puede asumir el caso de uso promedio basado en análisis y patrones de uso . Para evitar esto, los procesos de soporte y los canales de retroalimentación son vitales.

El apoyo puede tomar varias formas. Para algunas API, el soporte en vivo es muy útil. Estas API a menudo se encuentran dentro de la industria de servicios: sistemas de soporte de comercio electrónico, sistemas de tickets de solución de problemas, etc. El soporte continuo no solo constituye el mejor soporte para el usuario promedio; También puede informar a los desarrolladores sobre el estado actual de la API, las áreas problemáticas que aparecen constantemente y las necesidades no satisfechas del consumidor.

Otras API pueden sufrir este tipo de soporte en vivo. Las API de Evergreen que cumplen una única función en particular, como una API que sirve datos de hora local, necesariamente pueden limitarse solo a esa función. Después de todo, si una API solo sirve por tiempo, realmente no importa si un consumidor quiere una función de temporizador, una función de programación, etc., para eso no es la API. Dicho esto, puede haber casos en los que la API proporcione datos erróneos, no se sincronice correctamente con ciertos dispositivos o simplemente no funcione. En tales casos, el soporte asincrónico, como formularios de contacto de informes de errores, puntos finales de informes de errores, etc., puede cumplir una función vital.

Con todo esto dicho, ningún modo de apoyo o retroalimentación sobrevive a la primera pérdida de consistencia. Al observar la suma total de las vías de comunicación, un usuario puede caer rápidamente en un agujero negro: un ticket enviado aquí, un correo electrónico enviado allí, todo depende de que los desarrolladores utilicen estos datos de forma rutinaria y utilicen los sistemas que se ofrecen. Si un desarrollador nota que hay un sistema de retroalimentación disponible, es funcionalmente inútil si el desarrollador no procede a usar ese sistema. Con demasiada frecuencia, un proveedor ha creado un buzón de correo con un correo electrónico como “feedback@coolapi.com” solo para no comprobar nunca los comentarios durante el resto del ciclo de vida de la API.

Esto es especialmente importante cuando se observa que existen muchos tipos de mecanismos de apoyo y retroalimentación. Supongamos que una API tiene una función pública y puntos finales internos. En ese caso, puede ser la elección correcta tener diferentes opciones de aparatos de apoyo y retroalimentación dependiendo de quién sea la audiencia objetivo. En tales situaciones, la precisión y la coherencia son aún más importantes.

Finalmente, el modo de comunicación es tan consistente como el enfoque y el enfoque. Especialmente a nivel empresarial, la comunicación es esencialmente una forma de relaciones públicas. Como tal, todos los que participan en los canales de comunicación deben tener al menos algún tipo de capacitación, comprensión o conjunto de habilidades para brindar apoyo. Una experiencia de usuario consistente respaldada por un profesional capacitado y familiarizado con el producto principal promoverá una excelente experiencia de desarrollador. Una falla en la consistencia no se reflejará en la mala experiencia singular sino en la plataforma de soporte.

En última instancia, lo que es importante aquí es que se proporcione algún canal, y que el canal esté claramente demarcado, disponible y utilizado en el desarrollo central.

2. Cambio y control de versiones

Establecer procedimientos coherentes de control de versiones y obsolescencia

Quizás el área más crucial para garantizar la coherencia se encuentra dentro de los diversos aspectos técnicos de su API, esto incluye cómo evoluciona su servicio. El control de versiones es un método de gestión de cambios que busca garantizar que las implementaciones críticas, los cambios de interacción y uso y los paradigmas alterados se distribuyan e implementen eficazmente a todos los usuarios.

El control de versiones debe ser coherente y comunicarse correctamente. El control de versiones ineficaz puede ser extremadamente perjudicial para la API promedio y sus consumidores. Hemos hablado de esto en profundidad antes, y sugerimos leer nuestros pensamientos recopilados sobre las mejores prácticas de control de versiones de API y la comunicación de cambios .

En segundo lugar, tener una metodología coherente detrás de las API y versiones de API obsoletas y obsoletas es increíblemente importante. También hemos discutido esto antes , resumiendo el problema central de la siguiente manera:

“Los términos de baja y caducidad son algunas de las políticas más importantes para comunicar a los desarrolladores. Su comunicación aquí no solo protegerá su API actual, sino que si está migrando a otra cosa, probablemente también garantizará su éxito: los usuarios solo confían en los proveedores que se comunican. La extinción y desactivación eficaz e inteligente no solo es buena para su código, es buena para sus usuarios, el espacio API y la industria en general ".

3. Seguridad

Adopte una práctica de seguridad interna coherente

La seguridad es otra área donde la consistencia es increíblemente importante. Tener terminales consistentes con estándares de seguridad consistentes y métodos de respuesta y monitoreo de línea base es increíblemente importante. Cada pequeña falla de coherencia aquí puede agravar y abrir más vulnerabilidades que quizás ni siquiera sepa que existen.

Un problema de seguridad común es permitir diferentes puntos de acceso para diferentes clases de usuarios. Si bien esto ocurre con mayor frecuencia dentro del contexto de un "servidor de prueba" expuesto, esto también puede suceder con puntos finales de prueba para nuevas funciones. Cuando esos puntos finales se crean y se dejan abiertos una vez que su utilidad ha expirado, esto solo crea un riesgo de entrada.

Además, cualquier elección de seguridad realizada en toda la API debe aplicarse a la API en su totalidad. Cosas como la limitación de velocidad son excelentes para prevenir ataques de denegación de servicio, pero si esos límites no se aplican a credenciales elevadas, entonces está creando una falla masiva en su seguridad. En tal sistema, en el momento en que un actor de amenazas puede utilizar una credencial elevada, se crea una situación en la que su solución de seguridad masiva no existe para el actor de amenazas directo.

En última instancia, la seguridad no es una solución única. La "seguridad" en una API no es como cerrar una sola puerta y llamarse a sí mismos seguros; en cambio, es como inspeccionar el muro de un castillo de dos millas de largo en busca de debilidades, erosiones o puntos altos que se puedan atravesar. Es un proceso activo de inspección en busca de debilidades, aunque sean menores, y luego abordar esas debilidades para equilibrar la experiencia del usuario con el acceso restringido.

Lea también: Prueba de las 10 principales vulnerabilidades de seguridad de API de OWASP

4. Autenticación y autorización

Asegúrese de que las claves de API se manejen de manera responsable y promueva un comportamiento de manejo consistente

Un problema importante de coherencia es el procesamiento de la autorización y autenticación de usuarios. Si bien esta área específica de interés cubre un puñado de dominios, aquí discutiremos más específicamente algunos tipos generales.

En primer lugar, el uso de claves API y el almacenamiento de esas claves deben ser coherentes tanto en el proceso como en la ubicación. Las claves de API pueden ser extremadamente poderosas y, sin una estrategia adecuada, podrían quedar expuestas inadvertidamente, recibir demasiado poder o incluso usarse para fines completamente incorrectos. Las claves deben proporcionarse en función de un conjunto coherente de estándares, y solo deben crearse para acceder a un conjunto limitado de recursos para un propósito específico. No debe haber una "llave maestra". Lo más importante es que estas claves deben tener un sistema de revocación y caducidad consistente para garantizar que ninguna clave dure para siempre y que las claves se puedan reciclar y distribuir adecuadamente.

En segundo lugar, cuando se cierra o cancela una cuenta, debe manejar adecuadamente las credenciales asociadas dentro de un proceso de vencimiento establecido. La expiración incorrecta de los certificados es una fuente importante de ingreso a los sistemas por parte de usuarios no autorizados, ya que, cuando se combinan con un manejo deficiente de la clave API, pueden dejar valiosas fuentes de interacción completamente abiertas. Agregue a esto el hecho de que estas credenciales a menudo se pasan por alto como fuentes de inseguridad (dado que, en un momento, fueron confiables), y tiene una tormenta perfecta que resulta en un actor de amenazas que vuela "por debajo del radar".

5. Coherencia de la plataforma

El desarrollo impulsado por especificaciones puede garantizar que la documentación refleje los entornos de producción

Un último punto de coherencia es la unificación de la experiencia API desde la perspectiva de la documentación y la especificación . Al desarrollar una API, a menos que la especificación se utilice para crear la documentación directamente, existe la posibilidad de que la salida difiera de la entrada. Si bien esto suele ser menor y puede ser solucionado por un desarrollador atento, la realidad es que estas diferencias a menudo se propagan a través de múltiples versiones, lo que da como resultado una documentación que debe someterse a una revisión para que sea útil y valiosa de forma remota.

También es posible que si se utiliza la especificación para crear la API de salida, pero este proceso se realiza al comienzo de una serie de desarrollos, la salida final aún no coincidirá. La peor parte de este escenario es que el resultado es diferente sin causa aparente; Es más probable que este escenario se desarrolle sin que sea obvio para los desarrolladores que el escenario anterior.

En todo momento, los desarrolladores deben esforzarse por asegurarse de que sus documentos públicos y declaraciones en la especificación coincidan con las instancias implementadas reales y que el espíritu y los procesos se reflejen adecuadamente. Esto incluye garantizar que las numerosas salidas diversas que informan al usuario coincidan con las entradas, pero también incluye la coincidencia del objetivo y el propósito establecidos de la API que se reflejan en las funciones reales. No está bien que una API indique que su propósito es hacer algo, y una vez que el usuario ingresa a la API, no está claro exactamente cómo (o incluso si) lo hace, ese es el peor escenario posible para la experiencia del usuario.

Sea consistente

Estos puntos siguen siendo solo una parte del conjunto de herramientas de coherencia que los desarrolladores deben aplicar. Es importante recordar que ninguna lista será una guía completa para la coherencia porque la coherencia no es un estado final; la coherencia es mucho más una forma de pensar, una mentalidad que se aplica a lo largo del proceso de desarrollo. Ser coherente no significa cumplir con todas las posibles permutaciones y situaciones; en cambio, ser coherente es esforzarse al máximo para abordar todos los problemas conocidos y concebibles de coherencia en su API.

Sin embargo, cuando se tratan en conjunto, estos puntos deberían proporcionar un punto de partida sólido para cualquier API. La integración adecuada y el tratamiento adecuado más directo de las inconsistencias darán como resultado una experiencia mejor, más eficaz y más coherente para el usuario final y los desarrolladores que integran la API.

¿Qué opinas de nuestras áreas de coherencia? ¿Hay algunos puntos importantes que nos falten? ¡Háganos saber a continuación!

Publicar un comentario

0 Comentarios