Header Ads Widget

Ticker

6/recent/ticker-posts

Recetas para API Ninjas

 Una empresa global comparte sus ingredientes para una API holística

Cuando las empresas deciden que quieren convertirse en una "empresa que prioriza las API", el primer gran paso es crear una "estrategia de API primero". Eso implica grandes discusiones sobre los aspectos arquitectónicos y técnicos de la construcción de una API escalable, confiable y liviana.

Sin embargo, en nuestra Cumbre API de Austin 2019 , Sandip Dhummad y Amit Patel de S&P Global Ratings hablaron sobre cómo tal enfoque puede potencialmente descuidar la otra cara de la moneda. Sugieren que la mayoría de los diseñadores de API ven los lados de la moneda de la siguiente manera:

  • Crecimiento : ¿Qué hará que mis API sean un éxito en el mercado como las de Facebook, Twitter, Google, etc.?
  • Experiencia del desarrollador : ¿Qué hace que las API sean fáciles de usar y de usar para el consumidor?

Sandip y Amit teorizan que prestar demasiada atención al crecimiento por el crecimiento, el primero de los puntos anteriores, puede eclipsar el diseño reflexivo e intuitivo. En otras palabras, los proveedores de API que se centran demasiado en herramientas y tecnología pueden pasar por alto algunas de las complejidades del diseño de API.

A continuación, analizamos algunos de los puntos planteados por Sandip. La mayoría de ellos son detalles más pequeños que los desarrolladores pueden apresurar. Sin embargo, pensarlo adecuadamente podría informar en gran medida la dirección de una API.

Basamos esta publicación en una charla impartida por Sandip Dhummad y Amit Pate en el Austin API Summit.

¿Cuál es el propósito de su API?

Sandip sugiere que una de las grandes preguntas que se hacen las empresas es: "¿Qué importancia tiene esta API para impulsar el crecimiento?" Una pregunta válida, sin duda, pero no la única que tenemos entre manos. Menciona dos beneficios comerciales estratégicos clave de la implementación de una API:

  1. Atrae complementos de gran éxito
  2. Abrir ventanas a nuevos ecosistemas

Centrarse únicamente en el crecimiento como resultado (es decir, atraer complementos de gran éxito) podría ser un error, ya que se trata del destino deseado y no del viaje en sí. Podría ser más inteligente pensar en el crecimiento como un resultado natural de las personas que desean utilizar su API.

Sandip proporciona el ejemplo de IBM y Watson:

“Ellos [IBM] no construyeron un sistema diseñado a partir de Watson. Más bien, hicieron que Watson estuviera disponible como una API pública para que la gente pudiera explorar. Ahora están aprendiendo cómo las personas utilizan un sistema cognitivo para su beneficio ".

Ese enfoque de las API puede parecer un sacrificio noble, pero en realidad no lo es. Existe un beneficio implícito para los desarrolladores de API al fomentar la exploración y la experimentación. Como dice Sandip, "cuando expone sus productos y servicios como una API, los convierte en una plataforma ... La gente puede entrar y comenzar a construir sus aplicaciones, abriendo una nueva ventana de oportunidad para usted: aprender y comprender el valor de su datos."

Lea también: Cómo valorar sus datos al proporcionar una API

El diablo está en los detalles

Sandip describe cómo algunos desarrolladores de API, en lugar de no ver el bosque desde los árboles, no ven los árboles dentro del bosque. Es fácil planificar una API y pensar: “Está bien, esta será una API RESTful y usaremos la especificación OpenAPI . ¡Empecemos! ”… No consideran los detalles más pequeños.

Algunos de los ejemplos que da Sandip incluyen:

  • URI : tratar los URI con cuidado, usar todo en minúsculas y pensar dos veces antes de finalizar los nombres de los recursos
  • Mapeo : considerando la relación entre arquetipos y mapeo de acciones
  • Consultas : mantener los parámetros de consulta coherentes con la URI o definirlos en función del enlace de datos admitido por los lenguajes de backend
  • Excelentes documentos : documentos de API con capacidad de prueba / prueba en línea

Hemos escrito mucho sobre la importancia de la documentación de la API antes, pero puntos como el anterior reflejan detalles más granulares. Los proveedores deben ir más allá de la estética para considerar las mejores prácticas de diseño al construir su API.

Suavidad y seguridad

Por supuesto, crear una API es solo el primer paso para ofrecerla a los consumidores. La validación de datos de entrada es una parte integral para mantener su API funcionando sin problemas, sin mencionar su relación con la seguridad de la API . Sandip hace sugerencias como:

  • Aproveche los aspectos transversales para la validación de datos para evitar el código repetitivo.
  • Utilice marcos de validación / enlace de datos para aplicaciones Java.
  • Aproveche los mecanismos consistentes de manejo de errores .
  • Utilice la desinfección de entrada para protegerse contra ataques como XSS, SQL Injection, Header Bomb, etc.

Una API debe funcionar bien, responder con códigos de error útiles y cumplir con los estándares de seguridad. Sin estos elementos, los desarrolladores no elegirán depositar su confianza en un servicio.

Relacionado: Principales amenazas de seguridad de API en 2020: Entrevista del panel de expertos

Poder para el consumidor

Sandip también ensalza las virtudes de la flexibilidad y pone tanto control granular en manos de los consumidores desarrolladores. Por ejemplo, es inteligente tener en cuenta los dispositivos móviles . Problemas como la obtención excesiva o insuficiente , así como la expansión de servicios y versiones, pueden afectar a los consumidores de API que intentan trabajar en el contexto de las plataformas móviles .

  • Obtenga solo los campos seleccionados, con respuestas parciales para clientes móviles.
  • Los consumidores de API pueden conocer la forma de un objeto necesario mejor que el proveedor de servicios.
  • La ausencia de capacidad de respuesta parcial socava la eficacia del uso de API móviles.
  • Permita que los consumidores de API recuperen la definición de campos , lo que garantiza que siempre se proporcionen campos obligatorios.

Vale la pena repetir que, en el caso de una API externa, es crucial mantener contentos a los consumidores. Las API producidas deben cumplir inherentemente ciertas expectativas.

Velocidad y racionalización

El uso de un marco y una tecnología adecuados debería, en teoría, mantener su API funcionando a una buena velocidad. Sin embargo, una vez más, pasar por alto detalles específicos más finos puede resultar en una API lenta o que se interrumpa en mitad de la llamada.

Al intentar acelerar su API , Sandip y Amit sugieren lo siguiente:

  • Habilite el filtrado de respuestas basado en el contexto de la aplicación, dando a sus consumidores más rienda suelta para crear aplicaciones.
  • Para evitar tráfico de red extraño, implemente la paginación ( paginación de desplazamiento o token de continuación / basado en conjuntos de claves) cuando devuelva varios elementos.
  • Considere el almacenamiento en caché del lado del cliente / del lado del servidor para acelerar el rendimiento de la API.
  • Es una buena práctica comprimir las respuestas del servicio , especialmente para los métodos que devuelven una colección de objetos, utilizando un algoritmo de compresión o soporte de marco.

En el mundo de la tecnología, la velocidad es el rey; si hay una manera de acelerar el rendimiento de su API, entonces hacerlo es una obviedad. La mayoría de los webmasters comprueban periódicamente el rendimiento de la velocidad de su página No hay ninguna razón por la que los desarrolladores de API no deban monitorear y optimizar sus API de la misma manera.

Leer sobre El futuro del diseño de API

Pensamientos finales

Lo hemos dicho miles de veces antes, pero vale la pena repetirlo: no existe un enfoque de “talla única” cuando se trata de construir una API. Sandip y Amit, al ofrecer ejemplos de la vida real en nuestra Cumbre API de Austin, y su audiencia lo saben tan bien como cualquiera.

Sin embargo, el mensaje que extrajimos de su charla es que algunos desarrolladores de API se obsesionan con las plataformas y herramientas a expensas de ciertos detalles granulares.

Es por eso que es bueno considerar las mejores prácticas para cosas como la seguridad y la documentación de API mientras aún se encuentran en las etapas de planificación.

Si no lo hace, puede terminar con un primer rediseño de API que, si bien pone la API en primer lugar, coloca al consumidor tan abajo en la lista que no hay forma de que se quede.

Publicar un comentario

0 Comentarios