Skip to main content
Build the future with Agentforce at TDX in San Francisco or on Salesforce+ on March 5–6. Register now.

Aprender los beneficios de las API

Objetivos de aprendizaje

Después de completar esta unidad, podrá:

  • Definir la abstracción.
  • Nombrar los beneficios de utilizar una API.
  • Explicar los verbos HTTP y sus usos

Al configurar el equipo deportivo, la propietaria del gimnasio comienza a imaginarse lo que sería este proceso sin contar con especificaciones estándar para la energía eléctrica. El equipo no sería lo único por lo que preocuparse. Otros elementos como el cableado en las paredes, los dispositivos adicionales con los que se comparte el cableado, la manera en la que se genera la electricidad (granja eólica, planta nuclear, generador de carbón o paneles solares), incluso el lugar donde está ubicada la fuente de energía. Por suerte, no tiene que preocuparse sobre los pequeños detalles, solo tiene que conectarlo en cualquier enchufe.

Las API proporcionan un nivel similar de predictibilidad y fiabilidad. Ofrecen una conectividad creada para un propósito que normalmente está en contexto. La integración con las API se puede repetir y ampliar fácilmente. En muchos casos, implican un intercambio de valor recíproco. La dueña del gimnasio obtiene la energía para las cintas de correr de un sistema en el que puede confiar, y el proveedor de servicio puede medir y facturar su consumo.

Beneficios del uso de API

Las API facilitan una gran cantidad de oportunidades. Estas son algunas maneras en las que el software, los clientes, los integradores no profesionales (citizen integrators), los desarrolladores y sus equipos pueden beneficiarse del uso de las API.

Externalización

A efectos de reproducibilidad, cualquier dispositivo compatible (en este caso, el equipo del gimnasio) podría externalizar fácilmente sus requisitos eléctricos a un servicio, y esos dispositivos deberían obtener los mismos resultados. De manera similar, las API permiten que tome los datos y las funciones clave de una interfaz estándar previsible. Céntrese en crear aplicaciones, servicios y experiencias de clientes increíbles, no en averiguar cómo puede obtener información común pero con matices.

Considere la manera en la que Lyft confía en la interfaz estándar de Google Maps para importar mapas y geolocalización en su aplicación móvil. La creación de mapas nunca ha formado parte de la experiencia de los clientes a la hora de coger un taxi o una limusina. Pero las empresas de transporte privado como Lyft vieron una oportunidad para mejorar la experiencia de los clientes con mapas.

Gracias a la API con Google Maps, Lyft no tuvo que preocuparse sobre cómo conectar los mapas en su aplicación. Puede centrarse en los procesos empresariales que hacen que la experiencia de viaje sea increíble.

Aquellos de ustedes que aspiran a convertirse en Trailblazers de integración deberían sentir el instinto de usar las API de esta manera para crear una maravillosa experiencia de cliente. De ustedes dependería transmitir al resto de integrantes de la organización esta mentalidad.

Mayor movilidad

Los dispositivos de consumo pueden trasladarse fácilmente de un enchufe a otro. Por ejemplo, sin un enchufe compatible o ninguna especificación, la propietaria del gimnasio tendría que conectar directamente el equipo a las paredes del edificio. Esto requeriría conseguir las herramientas necesarias, exponer todos los cables y conectarlos. Por supuesto, también necesitaría tener conocimientos sobre los cables de la pared.

Mover equipos es muy sencillo gracias a una interfaz estándar (piense en las actualizaciones de software, las migraciones a un nuevo servicio o la ampliación de su centro de datos). Aunque el patrón de la interfaz cambie, que es lo que ocurre al pasar de América del Norte al Reino Unido, los dispositivos de consumo se podrán adaptar fácilmente gracias a la normativa bien definida y documentada.

Abstracción

Si pensamos en el gimnasio, las tomas eléctricas son una capa de abstracción del servicio subyacente, es decir, la electricidad. ¿Y qué es la abstracción? Es una manera de ocultar los detalles operativos de otro sistema.

Siempre y cuando el servicio proporcione 120 voltios de CA a la toma eléctrica de una manera estándar, el proveedor del servicio podrá cambiar cualquier detalle o proceso que tenga lugar desde la toma hasta la fuente de electricidad. Los cambios son intrascendentes para los dispositivos de consumo,

así como la conexión entre el gimnasio y la fuente original de electricidad: el aerogenerador. En el recorrido nos encontramos además con transformadores y tendido eléctrico.

Las API sirven de capa de abstracción entre los datos o la función que se proporcionan y la lógica necesaria para completar y ejecutar una tarea en el origen. En otras palabras, su software necesita saber cómo conectarse al otro sistema, no cómo este funciona.

Nota

La interfaz en la que se comunican los sistemas representa un conjunto de normas acordadas (de forma similar al estándar de 120 voltios de CA para la electricidad) que permite a las aplicaciones enviar solicitudes de un servicio y recibir datos o funciones (por ejemplo, la visualización de un mapa) a modo de respuesta. Todas las API tienen sus propios conjuntos de normas acordadas, lo que conocemos como contrato de API. Este contrato es el que permite usar la API en los contextos para los que se ha diseñado.

Mayor productividad de los desarrolladores

Cuando los programadores escriben código, pocas veces lo hacen desde cero. Las API están diseñadas para tomar de referencia una base de código existente y usarla cuando y donde sea necesario en lugar de intentar volver a crear todas esas funciones. Aunque la reutilización de código existente limita la diferenciación entre aplicaciones, una referencia a la API (lo que suele recibir el nombre de "llamar a la API") puede suministrar al programa los datos o la funcionalidad previstos. Teniendo en cuenta la forma en que las API realizan tareas comunes, e incluso no tan comunes, estas pueden minimizar el tiempo de desarrollo de aplicaciones de meses o incluso años a semanas.

Cuando los desarrolladores cuentan con este tipo de productividad, la empresa consigue una agilidad sin precedentes. Como se explica en Integración basada en API para la reinvención de las empresas, gracias a las API, es posible crear nuevos productos e inventar nuevas formas de hacer negocios mucho más rápido de lo que se hacía antes.

Uso de protocolos HTTP para acceder a datos

Aunque no hay reglas ni leyes que dictaminen exactamente cómo deben conectar los desarrolladores sus aplicaciones con una API, sí que se han establecido algunos estándares. Por ejemplo, cuando las aplicaciones se conectan a API en Internet, la mayoría de proveedores de API facilitan las conexiones a través de HTTP, o el protocolo de transferencia de hipertexto, que también se conoce como World Wide Web (red informática mundial).

No importa si se trata de una aplicación en su teléfono que llama a una API, si está recuperando su recuento de calorías actual mediante un navegador web o si guarda la información de su entreno mediante el software de un equipo para hacer ejercicio, el caso es que todo ello se basa de un conjunto especial de comandos HTTP denominados verbos.

Verbos HTTP

Descripciones

POST

Envía los datos solicitados a un servidor para su procesamiento

GET

Recupera los datos solicitados de un servidor

PUT

Actualiza y sustituye los datos existentes por nuevos datos que se envían en la solicitud

DELETE

Elimina los datos solicitados del servidor

En la mayoría de casos, el proveedor de servicios facilita una dirección web especial, conocida como extremo de API, para que el software se conecte mediante un verbo HTTP. A continuación, encontrará un ejemplo de FitBit.

GET https://api.fitbit.com/1/user/[id-usuario]/activities/date/[fecha].json

Observe que en lugar del común "www", FitBit utiliza "api". En este caso, los desarrolladores pueden usar el comando GET para devolver los datos necesarios y que se muestren en sus aplicaciones. En el caso de este extremo, la respuesta esperada incluirá la última actividad (carrera), así como el resto de desafíos deportivos que el usuario haya completado recientemente.

Si una cinta de correr utilizara esta API, podría mostrar un montón de información que le sería de gran utilidad al usuario. Fíjese en este ejemplo de la respuesta que se recibe tras enviar una solicitud GET a la API de FitBit.

API

Los datos de API de actividades y desafíos deportivos que se devuelven, como el Id. de actividad, la cantidad de calorías quemadas, la distancia, el número de pasos y mucho más, todo ello estructurado en un código que pueda leer fácilmente una máquina.

Por supuesto, la respuesta anterior no es muy intuitiva y nunca se presentaría al usuario de la cinta de correr. Tiene el formato correspondiente a otro estándar denominado JSON (JavaScript Object Notation) que suele utilizarse junto con el HTTP. Aunque parece muy técnico, hay un nuevo tipo de herramientas de integración de fácil uso, como MulseSoft Composer, que permite a los usuarios que no son programadores trabajar con este tipo de salidas. Esto permite a los integradores no profesionales imaginar nuevas formas de usar API y responder a esa imaginación mediante el desarrollo de esas integraciones. Mientras que los programadores podrían desarrollar algo de código para leer y procesar la respuesta anterior, un integrador con menos conocimientos, como el responsable de una línea de negocio o el diseñador de una cinta de correr, solo usaría clics.

Interfaz de la cinta de correr

Cuando la cinta de correr recibe una respuesta, el usuario ve el total de calorías quemadas, su progreso durante el desafío más reciente y mucho más.

La IU de la cinta de correr utiliza los datos recibidos desde la API de FitBit para informar al usuario de su estado actual.

Póngase ahora en el lugar del diseñador de la interfaz de usuario de la cinta de correr. ¿Tiene alguna idea de una interfaz de usuario diferente? ¿Quizás una que aproveche otros datos de la respuesta? Podría hacerlo sin duda. Este tipo de flexibilidad para realizar cambios en la interfaz de usuario es solo un ejemplo de los beneficios que se obtienen del tipo de abstracción que ofrecen las API.

Recuerde esto: las aplicaciones no tienen por qué usar solo una API a la vez. Una aplicación puede llamar a varias API y a varios proveedores de API. A menudo, estas aplicaciones compuestas reciben el nombre de "mashup" o aplicación híbrida, como una receta que puede incluir cualquier tipo de ingrediente. La única limitación en cuanto a lo que puede hacer con una "mashup" es su imaginación.

Gracias a las miles de API que los desarrolladores de software y los usuarios que no son programadores pero cuentan con herramientas de integración sencillas (integradores no profesionales) tienen al alcance en Internet (más de 23 000 según el último recuento de ProgrammableWeb.com), la Web se ha convertido en una plataforma programable que es igual de potente, si no más, que las plataformas programables como Windows, Mac y Linux. Es como un estante gigante repleto de especias al que siempre puede recurrir. Cuanto antes empiece a rediseñar los procesos empresariales y las experiencias de cliente de su organización a modo de "mashups" creadas a partir de ingredientes ya elaborados, antes conseguirá utilizar API que le permitan transformar su negocio.

Recursos

Comparta sus comentarios sobre Trailhead en la Ayuda de Salesforce.

Nos encantaría conocer su experiencia con Trailhead. Ahora puede acceder al nuevo formulario de comentarios cuando quiera desde el sitio de la Ayuda de Salesforce.

Más información Continuar para compartir comentarios