Exploración de los aspectos básicos de las API REST

SAP Subscription Billing utiliza un tipo específico de API llamado Representational State Transfer Application Programming Interfaces, también conocido como REST APIs.

Hablemos primero de las API.

Una API actúa como un protocolo de comunicación entre diferentes programas de software. Explica cómo deben interactuar entre sí, proporcionando un conjunto de reglas e instrucciones. Piense en una API como un "intermediario" que permite que los programas de software se comuniquen de manera eficiente. Sin las API, no sería posible disfrutar de la simple tarea de reservar una habitación de hotel en línea o actualizar el software a través de la nube.

Antes de analizar las API REST, veamos cómo funciona una API. Vea el siguiente vídeo.

Ahora que comprende el rol de las API, profundicemos en las API REST.

REST significa Representational State Transfer (Transferencia de estado representacional). Es un estilo arquitectónico para diseñar aplicaciones en red. Una API REST utiliza HTTP —una tecnología fundacional de Internet— para solicitar y enviar datos. Estos datos pueden funcionar con una variedad de formatos, incluidos XML y JSON.

El concepto de REST se basa en los recursos. Un recurso en REST API es el concepto fundamental para la descripción de la información; es cualquier información que se puede nombrar. Por ejemplo, al hablar de SAP Subscription Billing, una suscripción puede ser un recurso y un cliente puede ser otro. La importancia de utilizar recursos en lugar de una gran base de datos es que cada recurso tiene una URL única que puede enlazar o referenciar.

Una característica sólida de las API REST es su utilización de métodos HTTP estándar. Estos incluyen POST que agrega un nuevo recurso; GET recupera un recurso; PUT actualiza un recurso; PATCH permite una actualización parcial; y DELETE elimina un recurso.

Los métodos PUT y PATCH son similares ya que ambos actualizan un recurso. Por ejemplo, si tiene un perfil de usuario con campos como nombre, correo electrónico y contraseña, una solicitud PUT requerirá que envíe todos los campos incluso si solo desea modificar la contraseña. El uso de PATCH over PUT ayuda a evitar reducir el rendimiento del sistema con cambios innecesarios al tratar con grandes recursos o actualizaciones frecuentes.

Una llamada u operación de API es idempotente si tiene el mismo resultado, independientemente de cuántas veces se aplique. Una operación idempotente proporciona protección contra llamadas duplicadas accidentales que causan consecuencias no deseadas.

Por ejemplo, si envía repetidamente la misma solicitud DELETE a una URL específica, es probable que los siguientes intentos fallen porque los datos ya se han borrado. El estado final del servidor con los datos eliminados sigue siendo el mismo después de la primera solicitud DELETE. Incluso si falla la segunda solicitud, el método DELETE se considera todavía idempotente porque se ha alcanzado el estado final deseado y no cambiará con peticiones repetidas.

Por ejemplo, considere un recurso que cuente para cada vez que se realiza una solicitud de PATCH. La solicitud de PATCH para aumentar el contador en 1 no reemplaza el historial del contador. Cada solicitud de PATCH posterior incrementará el contador. Si vuelve a aplicar la misma solicitud PATCH, el resultado variará cada vez y aumentará el contador.

La elección de un método API REST idempotente depende de su aplicación o servicio.

La belleza de las API REST radica en su simplicidad. Las API REST no tienen estado, lo que significa que el servidor no necesita conocer el estado del cliente. Una solicitud de un cliente ya contiene la información necesaria para completar una solicitud.

Tenga en cuenta que los métodos REST no se consideran un estándar. Los métodos REST son un conjunto de principios rectores y son adoptados por la mayoría de los desarrolladores como una herramienta poderosa para estructurar las API debido a su simplicidad, escalabilidad y compatibilidad con la web.

Las API (Interfaces de Programación de Aplicaciones) y las API REST (API Representacionales de Transferencia de Estado) juegan un papel crucial en el desarrollo de software moderno y las interacciones digitales. Las API proporcionan una forma para que diferentes sistemas de software se comuniquen e interactúen entre sí. Las API REST se han convertido en un estilo de arquitectura popular y ampliamente adoptado para diseñar sistemas en red, especialmente en el contexto de servicios web y aplicaciones basadas en la nube.

Obtenga una clave API, también conocida como clave de servicio, visitando SAP Business Accelerator Hub, accediendo a su API y seleccionando el botón Mostrar clave API en la parte superior derecha de la página. Las claves de servicio ayudan a proteger las aplicaciones con un método de autenticación y autorización. Desempeñan un papel clave en la protección de las interfaces de aplicación y los datos garantizando que solo usuarios o sistemas autorizados y de confianza accedan a una API.

Una clave de servicio es un identificador único que proporciona acceso de credenciales a un servicio en particular y puede ayudar a gestionar y limitar el uso del servicio. Las claves de servicio se pueden regenerar si están comprometidas. Las claves de servicio suelen ser cadenas largas y complejas que son difíciles de reproducir, lo que dificulta a los usuarios no autorizados eludir las medidas de seguridad.

La autenticación con una clave de servicio comienza enviando la clave como parte de una solicitud a una API. El servidor compara la clave con la clave almacenada en el servidor. Si coinciden, la solicitud se autentica, al igual que un método típico de nombre de usuario y contraseña.

En SAP Subscription Billing, la autenticación inicial genera un identificador temporal o token de acceso conocido como token de portador. Mientras que las claves de servicio proporcionan una autenticación segura de los sistemas de confianza, los tokens de osa proporcionan un acceso seguro y temporal a los servicios después de la autenticación.

En SAP Subscription Billing, la autenticación inicial genera un identificador temporal o token de acceso conocido como token de portador. Mientras que las claves de servicio proporcionan una autenticación segura de los sistemas de confianza, los tokens de osa proporcionan un acceso seguro y temporal a los servicios después de la autenticación.

Los tokens de portador no están vinculados a un usuario específico; en su lugar, verifican que una solicitud proviene de una fuente autenticada anteriormente.

Tras una autenticación de clave de servicio exitosa, el servidor genera un token de portador firmado único y lo envía de vuelta al cliente. Este token se utiliza en lugar de la clave de servicio para autenticar solicitudes subsiguientes dentro de esa sesión. Un token de portador ayuda a reducir el riesgo de exponer una clave de servicio eliminando la necesidad de enviar la clave de servicio con cada solicitud.

Los tokens de portador se generan durante una duración limitada y se controlan mediante una fecha de vencimiento. El token deja de ser válido a partir del vencimiento. El usuario debe volver a autenticar la clave de servicio para generar un nuevo token de portador. Un token de portador ayuda a reducir la posibilidad de acceso a largo plazo por parte de un usuario no autorizado.

Mientras que las claves de servicio proporcionan una autenticación segura de los sistemas de confianza, los tokens de osa proporcionan un acceso seguro y temporal a los servicios después de la autenticación. A continuación, veamos cómo crear un token de portador y buscar API.