Tipos de API

Introducción

La mayoría de los comerciantes no quieren verse limitados por proveedores de software de terceros, pero carecen de los recursos para desarrollar soluciones comerciales patentadas desde cero.

Las API permiten a los comerciantes diseñar soluciones personalizadas mediante la integración de características y funcionalidades avanzadas desarrolladas por otras empresas.

Determinar qué tipo de API y protocolo se adapta a las necesidades únicas de su empresa es una decisión comercial a largo plazo.

Obtenga información sobre los tipos y protocolos de API y evite errores costosos desde el principio.

¿Qué es una API?

An API (Interfaz de programación de aplicaciones) es un conjunto de protocolos y declaraciones que permiten que una solución de software interactúe y brinde servicios a otro software. API es el medio para traducir datos de un programa para que otro programa pueda leerlos.

Las organizaciones usan API para exponer un producto de software, sus capacidades y datos en un formato legible por máquina. Los clientes internos y externos utilizan estos recursos para crear nuevos productos y ofrecer valor al cliente final.

Por ejemplo, un PSP (Proveedor de Servicios de Pago) revela Puntos finales API (ubicaciones digitales) para autenticación de pago y servicios de procesamiento. Los comerciantes no necesitan comprender el código fuente del sistema remoto; solo necesitan instrucciones sobre cómo conectar su solución al extremo de la API (es decir, integrar con la API).

Note: Descubra cómo usar la API de CCBill para agilizar y automatizar los flujos de pago en su tienda en línea. API de transacciones RESTful de CCBill la documentación explica cómo cobrar a los clientes utilizando tokens de pago.

Tipos de API

Una empresa puede utilizar diferentes API para crear soluciones comerciales únicas y aplicaciones orientadas al cliente. Según la política de lanzamiento y el ámbito de uso, existen cuatro tipos de API.

API públicas

Una API pública, a veces denominada API abierta o externa, está destinada a ser consumida por tantos clientes como sea posible. Los desarrolladores externos pueden acceder libremente a la documentación de la API y usarla para desarrollar y probar aplicaciones sin restricciones de licencia.

Las organizaciones comparten abiertamente las funcionalidades y los datos de su sistema para aumentar el conocimiento de la marca o como parte de una estrategia de penetración en el mercado.

API internas

Las empresas utilizan API internas para integrar aplicaciones y sistemas existentes o crear nuevas aplicaciones que agilicen los procesos comerciales. Mantienen el control total sobre el uso de la API y evitan que personas o aplicaciones ajenas a la organización accedan a los sistemas internos o se comuniquen con ellos.

Aunque las API internas solo se usan dentro de una organización, los desarrolladores no deben comprometer las funciones de seguridad, la autorización del usuario o la autenticación. Las empresas que manejan información confidencial de clientes, como datos de tarjetas de pago, deben asegurarse de que sus API internas cumplan con los Estándar de seguridad de datos PCI.

API de socios

Algunas organizaciones brindan acceso API a sus aplicaciones y bases de datos a otras empresas (socios) para aumentar los ingresos complementarios.

Una API de socio se usa a menudo para compartir información confidencial de clientes con socios comerciales conocidos, e incorpora funciones de seguridad avanzadas y fuerte autenticación de usuario mecanismos.

Las empresas asociadas celebran un acuerdo con términos de uso, costos y licencias de API claramente definidos. Los proveedores de API quieren asegurarse de que el acceso no se use de una manera que pueda dañar su reputación.

API compuestas

Una acción compleja como crear un pedido de carrito de compras requiere varios Llamadas API enviado a múltiples puntos finales de la API.

Las API compuestas permiten a los desarrolladores agrupar varias solicitudes de API en una única llamada de API y recibir una única respuesta a cambio. Las API compuestas son ideales para usuarios que necesitan recopilar datos de múltiples fuentes y realizar una tarea en particular. Al reducir la cantidad de solicitudes y respuestas de API, las API compuestas pueden mejorar los tiempos de carga y el rendimiento de las aplicaciones.

Nota: Lea nuestro artículo para obtener más información sobre Integración de API y cómo puede ayudar a agilizar los flujos de trabajo.

Estilos arquitectónicos API (Protocolos)

Los desarrolladores utilizan diferentes tecnologías y lenguajes de programación al desarrollar aplicaciones y servicios web. Una API debe ofrecer una estructura común con reglas y restricciones claras para permitir una comunicación clara entre dos soluciones de software diferentes.

Los cuatro protocolos de desarrollo de API o estilos de arquitectura ampliamente utilizados incluyen:

• RESTO
• RPC
• JABÓN
• GraphQL

Cada formato tiene ventajas y desventajas únicas según los casos de uso específicos y los objetivos comerciales.

RESTO

El estilo de arquitectura REST (transferencia de estado representacional) es popular para crear API consumidas por servidores web y aplicaciones web.

REST se basa en una arquitectura cliente/servidor, lo que permite a los desarrolladores separar los servicios de front-end y back-end. Esto permite que diferentes componentes evolucionen de forma independiente con el tiempo sin comprometer la estabilidad del sistema.

API REST son apátridas ya que los receptores no pueden mantener el estado de sesión de una solicitud anterior. No se retiene información de una llamada, lo que significa que cada sesión es independiente y se entiende de forma aislada.

Las API web que se adhieren a las restricciones REST se denominan API RESTful. Las API RESTful utilizan solicitudes HTTP (métodos) y parámetros codificados en URL para acceder a los recursos de la API. Los métodos RESTful HTTP comúnmente utilizados incluyen:  

• PUBLICAR
• PUT
• PARCHE
• BORRAR

RESTful admite muchos formatos diferentes para intercambiar y almacenar datos:

• Texto sin formato
• HTML
• Ñame
• XML
• JSON

Un ejemplo de una solicitud de API para crear un token de pago utilizando la API RESTful de CCBill:

var data = JSON.stringify({
  "clientAccnum": 900000,
  "clientSubacc": 0,
  "customerInfo": {
    "customerFname": "Tyler",
    "customerLname": "Thomas",
    "address1": "Woodland Drive",
    "address2": "Apt 21",
    "city": "Tempe",
    "state": "AZ",
    "zipcode": "85281",
    "country": "US",
    "phoneNumber": "5555555555",
    "email": "tthomas@xyz.com",
    "ipAddress": "10.70.60.14'",
    "browserHttpUserAgent": "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0",
    "browserHttpAccept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
    "browserHttpAcceptLanguage": "en-US,en;q=0.5",
    "browserHttpAcceptEncoding": "gzip, deflate, br"
  },
  "paymentInfo": {
    "creditCardPaymentInfo": {
      "cardNum": "4473707989493598",
      "nameOnCard": "Tyler Thomas",
      "expMonth": "04",
      "expYear": "2019"
    }
  },
  "subscriptionId": 900000000000000000,
  "timeToLive": 30,
  "validNumberOfUse": 3
});

var xhr = new XMLHttpRequest();
xhr.withCredentials = true;

xhr.addEventListener("readystatechange", function () {
  if (this.readyState === 4) {
    console.log(this.responseText);
  }
});

xhr.open("POST", "https://api.ccbill.com/payment-tokens/merchant-only");
xhr.setRequestHeader("Content-Type", "application/json");
xhr.setRequestHeader("Authorization", "Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOlsibWNuLXRyYW5zYWN0aW9uLXNlcnZpY2UiLCJtY24tYWRtaW4tc2VydmljZSJdLCJzY29wZSI6WyJjcmVhdGVfdG9rZW4iLCJyZWFkX3Rva2VuIiwiY2hhcmdlX3Rva2VuIiwiY3JlYXRlX3Byb2dyYW0iLCJyZWFkX3Byb2dyYW0iLCJjcmVhdGVfcHJvZ3JhbV9wYXJ0aWNpcGF0aW9uIiwicmVhZF9wcm9ncmFtX3BhcnRpY2lwYXRpb24iLCJtb2RpZnlfcHJvZ3JhbV9wYXJ0aWNpcGF0aW9uIl0sImV4cCI6MTUzNzM4MDczNiwiYXV0aG9yaXRpZXMiOlsiTUNOX0FQSV9UT0tFTl9DSEFSR0VSIiwiTUNOX0FQSV9UT0tFTl9DUkVBVE9SIiwiTUNOX0FQSV9BRE1JTiJdLCJqdGkiOiI4YzI2Njg1MC00NjMzLTQzZDMtYjZjOC1lNzIyY2ExNjQ1YTUiLCJjbGllbnRfaWQiOiI1MjE3NjhhYTc1OGQxMWU4YWE2YjAwNTA1NjlkMTU4NSJ9.HRYXZFATkIcI2_LJ1W_xo67IfBnbN9atyYNzyHqseLxYUxzgwBsAV5rNqCixKemOrDIeQLBN4jrwRsBIHDpEvshwBC8XmTodDJzpGmMaU9s1r20RV68X0_d1yTgSDke_Of7VCrVmJRbSuDl7AgsfTqQ1J7nWyu9vcIaER93ms-vadser_Ot9Z68_HAmCJL3DCLpdIFq3PYtBMKKKqXbvhfhSZQZD3b6-aewAnBo0VzpvK6tREqw1rv9_73oAvYcW2aHAj79ILr8viWMM40LyDKMMYOYkneg3hJUQsUVeh9WzztYUJKzERYNXje9fYIGN-eofoLvX7OZJ3eXmIfkrfQ");
xhr.setRequestHeader("Cache-Control", "no-cache");

xhr.send(data);

REST es un estilo de arquitectura flexible y escalable que puede admitir bases de clientes grandes y dinámicas, lo que lo hace ideal para las API públicas.

RPC

La llamada de procedimiento remoto (RPC) implica enviar una solicitud a un servidor remoto y recibir una respuesta estructurada. RPC se usa para iniciar acciones, a diferencia de REST API, que se usa para intercambiar documentos (recursos).

Las API de RPC están muy estructuradas y los desarrolladores pueden usar JSON o XML para codificar solicitudes y vincular recursos a propósitos y funciones específicos.

Las API de RPC no son adecuadas para un consumo público intenso. La API RPC se implementa mejor en un sistema orientado a microservicios, donde da como resultado un entorno más eficiente y estrechamente acoplado.

JABÓN

SOAP (Protocolo de objetos de acceso simple) es un estándar de mensajería que admite los protocolos de comunicación HTTP, TCP y SMTP. La mayoría de los sistemas operativos utilizan estos protocolos, lo que permite que las API basadas en SOAP impulsen los servicios web, independientemente de la plataforma o el lenguaje de programación subyacente.

SOAP tiene una estructura estricta y los desarrolladores deben codificar los mensajes SOAP como documentos XML. Mensajes SOAP contener hasta cuatro elementos:

• Sobre - Elemento raíz obligatorio que identifica el documento como un mensaje SOAP.
• Encabezamiento - Elemento secundario opcional utilizado para pasar información relacionada con la aplicación y agregar nuevas funcionalidades.
• Cuerpo - Elemento secundario obligatorio que contiene la información intercambiada con el destinatario.
• Fallo (manejo de errores) - Subelemento opcional del cuerpo SOAP utilizado para informar errores.

SOAP es ACID compatible y tiene seguridad WS integrada y compatibilidad con SSL. Los proveedores de administración de identidades, empresas de telecomunicaciones y fintech utilizan mensajes SOAP para garantizar la seguridad de las transmisiones de datos automatizadas.

La arquitectura SOAP se utiliza principalmente para soluciones API internas y de socios.

GraphQL

GraphQL es un lenguaje de consulta y un entorno de tiempo de ejecución del lado del servidor para las API. Agrega datos de múltiples fuentes y recupera los datos solicitados con una sola llamada a la API.

Un servidor GraphQL contiene un esquema predefinido que describe qué consultas están permitidas, los objetos y sus campos, y la relación entre los tipos de datos. Un desarrollador puede crear un esquema GraphQL y construir una interfaz a su alrededor utilizando cualquier lenguaje de programación.

El esquema permite a los usuarios validar posibles consultas de su editor y descubrir posibles problemas antes de enviar una solicitud. Los desarrolladores pueden eliminar de manera eficiente los posibles problemas de formato de datos al predecir los resultados de las consultas con anticipación.

GraphQL no requiere que el usuario aplique una arquitectura de aplicación específica y se puede usar junto con la API REST existente. Sin embargo, presenta una curva de aprendizaje empinada para los especialistas que trabajaron anteriormente con la arquitectura REST.

¿Cómo elegir un tipo de API?

Los comerciantes deben seleccionar el formato de API más apropiado para su proyecto en función de:

• Recursos disponibles (económicos, técnicos y de personal).
• La complejidad de los datos que necesitan intercambiar.
• Requisitos de seguridad de datos.
• Requisitos de rendimiento y velocidades de intercambio de datos.
• Los lenguajes de programación que admite un protocolo.
• El entorno de desarrollo en el que se desarrolla la solución.

Un formato básico, como RPC, es más fácil de desarrollar y administrar, pero es posible que no brinde suficiente protección para la información confidencial de los clientes que los comerciantes suelen tratar. Un protocolo API que ofrece un alto nivel de seguridad aumenta significativamente los costos de desarrollo y mantenimiento y obliga a los comerciantes a contratar personal especializado.

El curso de acción sensato es aplicar y probar un protocolo API en casos de uso limitados y extenderlo gradualmente a nuevos casos de uso antes de decidir.

Conclusión

Las API permiten a los comerciantes desarrollar soluciones comerciales patentadas e involucrar aplicaciones orientadas al cliente sin gastar una fortuna en integraciones largas y prolongadas.

Comprender los tipos y protocolos de API es un primer paso esencial para tomar una decisión comercial informada.