El mundo de las API
El origen de las APIs se remonta a finales de la década de los 60 cuando los primeros sistemas distribuidos de computación se empezaron a desarrollar. Aunque el primer protocolo que empezó a ganar popularidad fue RPC desarrollado por SUN Microsystems ya en 1988.
Su función es la de servir de punto de entrada bien documentado para interactuar con otros sistemas.
A lo largo de la historia estas interfaces de comunicación han ido cambiando. La revolución vino con SOAP creado por Microsoft, que empezó a utilizar XML para el intercambio de información entre aplicaciones y a utilizar HTTP como transporte; a diferencia de CORBA que hasta hace poco había sido el dominador y utilizaba protocolos binarios para la comunicación. SOAP, a pesar de tener peor rendimiento que los otros protocolos binarios, se impuso gracias a su simplicidad y facilidad de uso.
Esto provoco un crecimiento exponencial de servicios Web y que muchas compañías pudieran exponer servicios a terceros o consumir servicios de terceros. A partir de ese punto el modelo fue evolucionando. Se popularizo REST pudiendo usar múltiples formatos de datos, destacando JSON sobre los demás y facilitando aún más la creación de servicios web. Gracias a ello, se ha creado un ecosistema de integraciones que agiliza las operaciones y el intercambio de información entre distintas organizaciones.
Desde Axians utilizamos las APIs que nuestros partners ponen a nuestra disposición para mejorar el servicio final que damos a nuestros clientes. Una de nuestras aplicaciones prácticas es la utilización del API de soporte de Cisco (https://developer.cisco.com/site/support-apis/), accesible por partners que den servicio de soporte.
Previamente es necesario tramitar con Cisco el acceso y crear un usuario para poder consumir el servicio, lo que permite acceder a esa información de manera segura.
El poder utilizar estos servicios además es muy sencillo y sin grandes conocimientos de programación podemos hacerlo; por ejemplo, el siguiente programa escrito en Python que realiza una consulta al API REST de Cisco para consultar las fechas de fin de vida suministrando un número de serie de un equipo de Cisco.
import requests
import json
CLIENT_ID = "XXXX"
SECRET = "XXXX"
def api_get_token ():
headers = {'Content-Type': 'application/x-www-form-urlencoded'}
data = [
('client_id', CLIENT_ID),
('client_secret', SECRET),
('grant_type', 'client_credentials')
]
output = requests.post('https://cloudsso.cisco.com/as/token.oauth2',headers=headers, data=data, verify=True)
return output.json()
def get_eox_serial (token, serial):
get_headers = {
'Accept': 'application/json',
'Authorization': 'Bearer {}'.format(token['access_token'])
}
url = https://api.cisco.com/supporttools/eox/rest/5/EOXBySerialNumber/1/+serial
output = requests.get(url , headers=get_headers, verify=True)
return output.json()
if __name__ == '__main__':
token = api_get_token()
result = get_eox_serial(token, 'XXXX')
print ("**** GET EOX ****")
print (json.dumps(result, indent=4, sort_keys=True)) Brevemente podemos ver como primero utilizamos la función de autenticación api_get_token() para obtener un token que nos servirá de clave para poder realizar consultas. Después llamamos a la función get_eox_serial() que recibe el token de autenticación y el número de serie del equipo que queremos verificar, por último mostramos el documento que nos devuelve el servidor de Cisco, un documento en formato json:
**** GET EOX ****
{
"EOXRecord": [
{
"EOLProductID": "N9K-C9396PX",
"EOXExternalAnnouncementDate": {
"dateFormat": "YYYY-MM-DD",
"value": "2017-08-05"
},
"EOXInputType": "ShowEOXBySerialNumber",
"EOXInputValue": "SAL1813NZB7",
"EOXMigrationDetails": {
"MigrationInformation": "",
"MigrationOption": "See Migration Section",
"MigrationProductId": "",
"MigrationProductInfoURL": "",
"MigrationProductName": "",
"MigrationStrategy": "Customers are encouraged to migrate to the Cisco Nexus 9300-EX and 9300-FX Series Switches. Information about these products can be found at http://www.cisco.com/c/en/us/products/switches/nexus-9000-series-switches/datasheet-listing.html",
"PIDActiveFlag": "Y"
},
"EndOfRoutineFailureAnalysisDate": {
"dateFormat": "YYYY-MM-DD",
"value": "2019-05-01"
},
"EndOfSWMaintenanceReleases": {
"dateFormat": "YYYY-MM-DD",
"value": "2019-05-01"
},
"EndOfSaleDate": {
"dateFormat": "YYYY-MM-DD",
"value": "2018-05-01"
},
"EndOfSecurityVulSupportDate": {
"dateFormat": "YYYY-MM-DD",
"value": "2021-05-01"
},
"EndOfServiceContractRenewal": {
"dateFormat": "YYYY-MM-DD",
"value": "2022-07-30"
},
"EndOfSvcAttachDate": {
"dateFormat": "YYYY-MM-DD",
"value": "2019-05-01"
},
"LastDateOfSupport": {
"dateFormat": "YYYY-MM-DD",
"value": "2023-04-30"
},
"LinkToProductBulletinURL": "https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/eos-eol-notice-c51-739452.html",
"ProductBulletinNumber": "EOL11923",
"ProductIDDescription": "Nexus 9300 48p 1/10G SFP+ & additional uplink module req.",
"UpdatedTimeStamp": {
"dateFormat": "YYYY-MM-DD",
"value": "2017-08-28"
}
}
],
"PaginationResponseRecord": {
"LastIndex": 1,
"PageIndex": 1,
"PageRecords": 1,
"TotalRecords": 1
}
}De esta manera se puede acceder fácilmente a información que luego puede ser tratada y combinada para ofrecer servicios de mayor valor.
Como puede ser generación automática de informes con información de soporte de los equipos, notificaciones automáticas para avisar el fin del mantenimiento de determinados equipos, etc.
El caso de uso ya depende de como queramos integrarlo en nuestros procesos de negocio, lo más importante es ver las todas las ventajas y posibilidades que tenemos utilizando esta manera de intercambiar información.
