Header Ads Widget

Ticker

6/recent/ticker-posts

Cómo el diseño de API inteligente promueve el desarrollo sostenible de aplicaciones

 



Con la industria tecnológica evolucionando rápidamente, reducir el tiempo de desarrollo se ha vuelto absolutamente crucial. Tanto para las empresas de software establecidas como para los desarrolladores independientes, el éxito requiere una toma de decisiones rápida. Afortunadamente, las mejores prácticas de diseño de API han venido al rescate. Poner en práctica estas prácticas garantiza una mayor seguridad, eficiencia y escalabilidad para sus aplicaciones.

Amjad Afanah , cofundador de FX Labs , está enfrentando estos desafíos de frente. Afanah está reescribiendo el libro de jugadas de API para enfatizar estándares nuevos y mejorados. Repensar las prácticas defectuosas puede aumentar la rentabilidad y, al mismo tiempo, hacer que las aplicaciones sean lo suficientemente robustas para soportar un crecimiento exponencial.

Vea a Amjad Afanah presente en la Cumbre de la Plataforma:

Compartiremos y ampliaremos algunos de los puntos de conversación de Amjad a continuación:

Manejo de recursos REST por tipo

Al diseñar API sólidas, es fundamental hacer un balance de sus diversos recursos. Estos recursos representan los datos a los que una API determinada puede acceder tanto del lado del cliente como del lado del servidor. Los desarrolladores de API asignan identificadores uniformes de recursos (URI) a estos recursos, que dictan cómo se hace referencia a los elementos.

La semántica juega un papel importante al realizar llamadas API exitosas. Afanah sostiene que los desarrolladores deberían evitar el uso de sustantivos en lugar de verbos, a menos que se refieran explícitamente a acciones. Es crucial que usemos convenciones de nomenclatura adecuadas para cada recurso. Pero ¿por qué es este el caso?

Hay cuatro categorías de recursos REST:

  • Documentos
  • Colecciones
  • Historias
  • Controladores

Primero abordemos brevemente los controladores, ya que son las excepciones:

Al diseñar las API REST, se requieren verbos para acceder a los recursos del controlador . Los controladores involucran operaciones de procedimiento, de acuerdo con el Libro de reglas de diseño de API REST , lo que hace que este requisito sea tanto lógico como natural. Por ejemplo, las aplicaciones pueden utilizar API específicas para la autenticación o realizar cálculos basados ​​en entradas.

POST /alerts/111234/resend

Estos recursos y sus hermanos son únicos, ya que no se conectan con métodos estándar: crear, recuperar, actualizar y eliminar (CRUD).

A continuación, tenemos tiendas , que los desarrolladores siempre deben denotar utilizando sustantivos en plural. Dado que las tiendas son repositorios de recursos de un tipo determinado, a menudo se hace referencia a ellas por categoría. Por ejemplo:

http://api.example.com/library-management/users/{id}/songs

El cliente asigna inicialmente URI a los artículos dentro de las tiendas y, por lo tanto, no generan URI adicionales.

Similar a las tiendas son las colecciones , que también se indican con sustantivos en plural. Mientras que los clientes administran las tiendas, los servidores administran las colecciones. Las colecciones seleccionan y eligen qué recursos aceptar y, por lo tanto, pueden generar URI para cada uno. Cumplir con las convenciones de nomenclatura en plural en todo el código de la API garantiza que el mapeo siga siendo coherente para el usuario. Por ejemplo, especificar ambos /resource/resourcesprovoca confusión con el enrutamiento. Lo mismo se aplica a las tiendas, en esencia.

Por último, los documentos se indican mediante convenciones de nombres singulares. Un documento es un registro singular y se refiere a una instancia. El tipo de documento destaca por actuar como una especie de base para otros tipos de recursos, debido a su estructura. Puede tener hijos y, por lo tanto, actúa como el recurso raíz de la API :

http://api.soccer.restapi.org/leagues/seattle 
http://api.soccer.restapi.org/leagues/seattle/teams/trebuchet
http://api.soccer.restapi.org/leagues/seattle/teams/trebuchet/players/mike

Por último, evite diseñar recursos que sean híbridos de dos tipos REST. Esto asegura un diseño de API consistente y mantiene su estructura de enlaces predecible.

El manejo de errores es importante

Al diseñar una API de calidad, debe crear estados de error lógicos para los usuarios finales. Cuando se realiza una llamada no válida, pero no se da retroalimentación, puede causar frustración y confusión. Los errores de API deben basarse en códigos de estado lógicos y contextuales organizados por tipo de problema. La asignación de estos mensajes descriptivos garantiza que los usuarios no se queden a oscuras.

Es posible que también se requiera cierta ofuscación por motivos de seguridad. No desea brindar accidentalmente a los atacantes información sobre la estructura central de su API:

“El manejo de errores es extremadamente importante y también es importante desde una perspectiva de seguridad, específicamente para el código de estado 500. Debe tener mucho, mucho cuidado de no volcar todo el seguimiento de la pila cuando ocurre un error interno del servidor. De lo contrario, les está dando a los piratas informáticos la oportunidad de realizar ingeniería inversa y averiguar cómo funciona realmente su aplicación ... "

Afanah también señala el delicado equilibrio entre seguridad y claridad. En última instancia, se debe proporcionar a los usuarios finales un razonamiento amplio sobre por qué se está produciendo un error sin revelar demasiado. Esta carga útil de error debe ser informativa o no tiene ningún propósito de redención.

Pasemos rápidamente al ejemplo de Amjad, centrado en el código de error 403 Prohibido . Si bien la autenticación es exitosa, esa solicitud también puede estar prohibida. En estos casos, Afanah sugiere proporcionar comentarios en la carga útil, como "no tiene suficiente crédito para completar esta transacción". Esto les da a los usuarios una mejor idea de por qué no se ejecutó la función API.

Monolitos frente a microservicios

Generalmente, es más fácil comenzar a desarrollar con bases de código monolítico . Las configuraciones monolíticas generalmente incluyen un repositorio de código fuente centralizado , al que los ingenieros pueden acceder fácilmente. Contiene herramientas y dependencias compartidas. Muchas grandes empresas, especialmente Facebook, Microsoft y Google, han adoptado este modelo.

Sin embargo, Afanah se apresura a enfatizar algunos inconvenientes de este método. Cuando la base de código crece rápidamente, resulta difícil lanzar actualizaciones de funciones. Es un desafío clasificar muchas dependencias. Además, las pruebas de un extremo a otro deben completarse cuando solo se modifica una función. Esto hace que el desarrollo sea engorroso y caro.

Por el contrario, los microservicios son adecuados para el desarrollo ágil. Dado que las funciones están esencialmente en silos, se requieren menos pruebas. Esto significa que las empresas y los desarrolladores de API pueden trabajar con rapidez. Esto también aumenta la escalabilidad. Sin embargo, vincular microservicios puede ser complicado cuando se trata de múltiples dependencias.

Prácticas recomendadas de seguridad de API

Podría crear la API más funcional y robusta que existe. Sin embargo, las medidas de seguridad adecuadas son esenciales para mantener viable su API. Los usuarios estarán mucho más dispuestos a utilizar su API si es menos susceptible a las vulnerabilidades. Esto es especialmente cierto para los clientes empresariales.

Un método común que utilizan los atacantes para interrumpir los servicios es un ataque de denegación de servicio distribuido (DDoS). Dado que la mayoría de las API están alojadas en servidores web, los atacantes pueden inundar estos servidores con solicitudes. Cuando esto alcance un volumen crítico, sus servicios ya no serán accesibles. Cuando tiene muchos usuarios, el tiempo de inactividad es un gran problema.

Afanah aboga por límites de paginación simples , que pueden mitigar el tráfico de red innecesario. De lo contrario, las búsquedas teóricamente podrían devolver millones o miles de millones de resultados a la vez. Esto puede abrumar fácilmente a sus servidores. Usar LIMITOFFSETrestringe cuántos recursos pueden llamar los usuarios en un momento dado, preservando el ancho de banda.

El control de acceso basado en roles (RBAC) , aunque útil, no es una fórmula mágica. Al incorporar el control de acceso en los sistemas de autenticación, los arquitectos de API incluirán múltiples permisos finamente ajustados. A medida que esta lista crece, se vuelve más difícil de mantener y requiere más recursos. Si las empresas no invierten en un mantenimiento continuo, pueden desarrollarse vulnerabilidades. Los usuarios de API pueden obtener un acceso elevado a los recursos cuando se pierden las verificaciones. Como afirma Amjad, esto no es intencionado y puede ser muy dañino. Estos usuarios pueden acumular roles innecesarios, facilitando este resultado.

Por último, los piratas informáticos pueden emplear inyecciones de SQL y ataques de datos para acceder a información confidencial y extraer datos. Los atacantes también pueden borrar o alterar datos importantes. Afortunadamente, existen muchas herramientas que ayudan a detectar estos errores de codificación antes de que se publiquen.

Prácticas recomendadas para las pruebas de API

Afanah presenta cinco prácticas clave para las pruebas de API, centrándose en la facilidad de uso:

  • Pruebas estandarizadas
  • Pruebas basadas en datos
  • Ejecución de prueba distribuida
  • Gestión de errores automatizada
  • Prueba de seguridad API

Cada uno tiene distintas ventajas sobre otros métodos. Vamos a desglosarlos uno por uno:

Las pruebas y la redacción estandarizadas son importantes para un enfoque basado en equipos. El uso de un lenguaje de marcado permite a los desarrolladores centrar su atención en una herramienta. Esto es útil ya que el desarrollo es un proceso en el que los compañeros de equipo pasan código.

Las pruebas basadas en datos realmente se enfocan en tomar un conjunto de datos centrales y aplicarlo en otro lugar. En lugar de crear nuevas pruebas cada vez, los desarrolladores pueden reutilizar las pruebas anteriores. Cuando las pruebas se multiplican mucho, ejecutarlas resulta ineficaz.

La ejecución de pruebas distribuidas se implementa teniendo en cuenta la escala. Cuando las pruebas se ejecutan de forma inteligente en paralelo, se reducen drásticamente los plazos de entrega y se permite una mayor asignación de recursos.

La gestión de errores automatizada, argumenta Amjad, debe estar algo automatizada. De lo contrario, el seguimiento de problemas puede volverse abrumador rápidamente.

Por último, las pruebas de seguridad API deben aplicarse lo antes posible en el proceso de desarrollo. Es mucho más sencillo evaluar las vulnerabilidades del código de forma progresiva, en lugar de auditar una base de código masiva.

Pruebas tradicionales frente a Shift-Left

Afanah es un gran defensor de las pruebas al principio de la fase de diseño. En el ciclo de vida de las pruebas tradicionales, los errores se vuelven cada vez más costosos de resolver:

Cuando detectamos estos errores antes, cuestan menos por dos razones principales: se requiere menos tiempo para resolverlos y tienen un impacto relativamente menor en la API.

Cuando cambiamos las pruebas hacia la izquierda, la detección de errores se vuelve más simple. Menos costos asociados significa menos impacto financiero. Dado que las nuevas empresas y las pequeñas empresas son especialmente sensibles a los problemas financieros, las pruebas tempranas son cruciales. De acuerdo con las Estadísticas Internacionales de Violación de Datos del Ponemon Institute, el 60% de las startups cierran dentro de los seis meses posteriores a un ataque. Esto hace que las pruebas proactivas sean esenciales.

Según esas mismas estadísticas, el 89% de las infracciones y la pérdida de datos podrían haberse evitado mediante pruebas adecuadas. Tómese el tiempo para galvanizar su API contra amenazas externas. Después de todo, el código escrito recientemente estará más fresco en su mente que el código escrito semanas antes.

El cuento cauteloso de GitLab

Afanah hace referencia a problemas de seguridad anteriores con la API de eventos de GitLab para resaltar esto. Una vulnerabilidad llevó a la exposición de innumerables problemas confidenciales del proyecto. Este problema de seguridad no se detectó hasta un año después. Dado que la API de eventos había sido ampliamente adoptada, GitLab tuvo que notificar a muchos desarrolladores. Como resultado, GitLab invirtió una gran cantidad de dinero para resolver estos problemas.

Amjad también argumenta en contra de confiar en programas de recompensas por errores. Cuando los usuarios descubren e informan sobre estos problemas, el costo de solucionarlos ha aumentado enormemente. Si es demasiado caro, es posible que las empresas deban retener los arreglos hasta que haya fondos disponibles.

Notas de cierre

Amjad cierra su discusión volviendo las cosas a FX Labs, explicando las mejores prácticas de diseño de API que emplean a diario. Es importante reiterar brevemente los beneficios de la seguridad y las pruebas paralelas.

El desarrollo de API es cada vez más complejo a medida que las herramientas se vuelven más poderosas. Tener en cuenta estas pautas le dará a sus proyectos futuros la mejor oportunidad de éxito. Estas mejores prácticas de diseño de API deberían ser su proyecto de futuro.

Recursos:

  • Mejores prácticas para el diseño de API para mantener su aplicación segura, escalable y eficiente
  • Libro de reglas de diseño de API REST
  • Ventajas y desventajas de un repositorio monolítico, API de Google

Publicar un comentario

0 Comentarios