¿Qué es un endpoint de API?

Los endpoints de API suelen encontrarse en la documentación de una API, que es donde los desarrolladores ponen información de la API, como qué tipo de solicitudes aceptará una API y cómo deben formatearse las solicitudes. Lo ideal sería que esta documentación también incluyera una lista de todos los endpoints de API disponibles y una breve descripción de sus funcionalidades.

En un contexto de API REST (un estilo arquitectónico de software utilizado con frecuencia para las aplicaciones web), el proceso tiene este aspecto:

El proceso comienza cuando un cliente de API envía una solicitud de recursos (llamada a API) al endpoint de API correspondiente. Se accede a los endpoints mediante métodos de solicitud HTTP como POST, GET, PUT, PATCH y DELETE. Estos métodos indican la acción que el cliente desea realizar sobre el recurso especificado.

Por ejemplo, si un cliente desea recuperar una lista de los totales de medallas olímpicas de un determinado año de la hipotética base de datos Olympicfacts.com, se envía una solicitud GET a la siguiente dirección URL de endpoint: 

https://api.olympicfacts.com/v1/{year}

Esta solicitud devolvería una lista del total de medallas olímpicas por país. (v1 en nuestro endpoint hipotético indica la versión de la API, una práctica común en el control de versiones de API). Si el cliente quisiera un total para un país específico en un año determinado, se agregaría un identificador a la URL base: 

https://api.olympicfacts.com/v1/year/{id}

En este ejemplo, el identificador {id} se utiliza para indicar sobre qué país desea recibir información el cliente.

Además, una solicitud puede incluir:

• Encabezados: los encabezados pueden proporcionar información adicional sobre la solicitud, como un encabezado de aceptación que especifica los tipos de medios aceptados
  
  
• Parámetros: se pueden agregar parámetros de consulta a la URL base o en el cuerpo de la solicitud para filtrar aún más los criterios de búsqueda o agregar otras especificaciones.
  
  
• Cuerpo de solicitud: un cuerpo de solicitud incluye los datos necesarios para crear o modificar un recurso. Por ejemplo, si la solicitud es para crear un nuevo blog (solicitud POST), el contenido del nuevo blog se incluiría en el cuerpo de la solicitud.
  

Una vez que el servidor autentica la solicitud y valida la entrada, recupera los datos solicitados y devuelve la respuesta al cliente. Muchas organizaciones utilizan API Gateway para ejecutar estas funciones y administrar el flujo de tráfico de API.

La clave de cualquier buen diseño de API es la fase de prueba. Las aplicaciones modernas suelen utilizar API para integrar funciones de otro software o se crean mediante arquitecturas de microservicios (que se basan en las API para la comunicación entre distintos servicios). Probar los endpoints de la API es esencial para garantizar la fiabilidad.

Existen opciones de prueba manuales para las API y opciones de prueba que utilizan la automatización, así como numerosas herramientas y plataformas de prueba (tanto de código abierto como propias) que las empresas pueden utilizar.

Las pruebas manuales de endpoints de API pueden ser más lentas y menos eficientes, pero también más precisas y personalizadas para casos de uso específicos. Las pruebas funcionales consistirían simplemente en enviar una solicitud desde una aplicación para asegurarse de que se da la respuesta correcta. En un ejemplo de redes sociales, esto podría significar enviar una solicitud de una nueva publicación por parte de un usuario en particular y verificar que la publicación devuelta sea realmente la correcta.

Otros tipos de pruebas manuales implican: 

• enviar muchas solicitudes a la vez para ver cómo el servidor maneja la carga de solicitudes
  
  
• comprobar que la API se integra correctamente con otros servicios
  
  
• determinar la velocidad y el tiempo de respuesta de una solicitud determinada
  
  
• proporcionar intencionalmente una solicitud no válida para comprobar que se devuelve el mensaje de error correcto

Las pruebas automatizadas realizadas a través de una plataforma de gestión de API pueden ofrecer varias ventajas:

• reduce la posibilidad de error humano
  
  
• es más eficaz a la hora de comprobar la validez de varios endpoints de API
  
  
• puede mejorar la velocidad de las pruebas y reducir potencialmente los costes a largo plazo una vez que se establezcan sistemas de pruebas automatizados (ahorrando tiempo de los empleados, por ejemplo)
  
  
• alinea las pruebas con protocolos, estándares y permisos uniformes

En general, cada uno debe devolver la respuesta deseada, en términos de formato, datos devueltos y código de estado.

Dado que los endpoints de API proporcionan una forma de que las aplicaciones y sistemas internos y externos accedan a los datos y los integren, también presentan un posible punto de entrada para los malos actores. Los ataques de denegación de servicio distribuido (DDoS) pueden utilizar solicitudes legítimas, pero en cantidades absurdas, para inundar un servidor. Otros tipos de ataques pueden intentar utilizar los endpoints de la API para extraer más información de la que el cliente está autorizado a recibir o utilizar los endpoints de la API para instalar malware o código malicioso.

Hay varias formas en que una organización puede mantener la seguridad de sus endpoints de API y la seguridad general de la API, entre ellas:

Los recursos de API son conjuntos de datos u objetos que proporcionan las API. Los recursos varían según la API en cuestión, pero los tipos de contenido incluyen texto, tablas, archivos fuente, audio, vídeo, imágenes, usuarios, productos y mucho más.

Un endpoint de API es la ubicación específica de esos recursos en un servidor. Es un punto de contacto entre un cliente API y un servidor, donde se dirigen las llamadas API.

Piense en el anuncio de una tienda. El listado proporciona la ubicación de la tienda (endpoint) y cómo contactarla para solicitar información como el horario de la tienda y el inventario de productos (recursos).