The SDK (Software Development Kit) is the software toolbox for Developers!
Unlike an API which is basically a set of URI’s that are executed per the requirements of documentation used to help build them, SDK’s are a set of tools for a specific device or system, often containing packages / integrated with libraries / documentation / code samples / Etc.
For something more specific like iOS / Mac / Apple devices you will likely need SDKs to pull resources from that are not commonly available as open-source, whereas something like an API utilizing Google Maps it may just be more of an execution of API calls with proper Auth creds to allow the software to execute, thus the URIs succeeding in their execution for the software.
SDKs can provide for simpler auth mechanisms / token refreshes for APIs, as well as allowing for easier Pagination and API Rate Limits, and the examples of sample code specific to the programming language required for that software to assist in development.
One important note – I will post links to each different Platform SDK that you will want to visit the page on Cisco’s Developer site to review it and possibly play with it in Sandbox!
Click on the links, review documentation, go to the sandboxes and schedule some time to just play around and get to know the Platforms at even a high level understanding – But a solid understanding of how API’s and Data flows and interacts in terms / terminology of “Intent Based” APIs and Directional Flows like Northbound / Southbound / Etc.
Note on what in the world “Pagination” is – This word has been kind of a mystery to myself so I wanted to note that Wikipedia defines this in Web Applications / Software Development as distributing “electronic” or “discreet” paging so that it is more human digestible.
Cisco WebEx / Jabber / UCS / APIC Python (Cobra SDK) / CIMC / Instant Connect SDKs!
This won’t be an exhaustive list of SDK’s as I feel there is only a need for how they interact with Cisco Platforms for exam purposes, however I think that working with them is the best way to really understand how they function in development, however for exam purposes I will only be covering the details and “need to knows” for SDKs in this post for Cisco Platforms.
This picture below for WebEx SDKs and API’s demonstrates their differences:
Note that the API Documentation is more an instruction manual of how the API is built as a piece software or application feature, whereas SDKs are specific to the Platform / OS that the API is being developed for to bring the tools of that Platform to the developer to work with.
Below is pulled from WebEx documetation regarding another important topic, Webhooks:
These are part of the API and Integration with services, I know them currently in a fairly limited capacity in a Meraki context of Webhooks being used to trigger events to a remote service if an event hits that trigger to make an API Call via Webhook.
With Webex this trigger could be sending a message will result in notifying someone they have a new message / creation or deleting a new room / Etc. Webex uses a lot of people / room / email IDs in their SDKs, and the main SDK relies heavily on Python as the API / SDK language.
https://developer.webex.com/docs/sdks/ – For more information on Webex SDKs
Jabber / Jabber Guest / Jabber for Android
These SDKs are found under the “Collaboration” content on Cisco Developer website as this goes back to utilizing the old on-prem server roles like CUCM / CUC / Presence (CUPS) to allow for development of software that revolves around those services as you may not have a CUCM Environment on hand to aid in the development of these API’s or Software.
The API for Jabber related functions has an SDK that handles the secure connection / User Auth / Initiation of Video or Audio conferencing calls between endpoints either use a Web Page, iOS, Android, and many other platforms.
https://developer.cisco.com/jabber-web/ – For more information on Jabber SDKs
DNA Center SDKs
A lot of this is inherent to Python programming language / PIP installation, alongside Ansible, there is a lot to know there so I would recommend visiting the site and checking out the documentation : https://developer.cisco.com/docs/dna-center/#!python-sdk-getting-started.
Cisco APIC Python SDK (Cobra SDK)
Cobra SDK is native to Python for binding a REST API with the APIC Controller, which relies on two good to know install files: acicobra.egg / acimodel.egg – Please check out the URL below:
https://cobra.readthedocs.io/en/latest/install.html – For APIC Cobra SDK Details
Cisco UCS SDKs
Uses a Python Module to automate all aspects of UCS Management including Server / Network / Storage / Hypervisor manage, details @ https://ciscoucs.github.io/ucsmsdk_docs/
Cisco Instant Connect
This SDK provides a Tool-Kit to allow for Push-to-Talk features in mobile and desktop applications, which more details can be found at:
https://developer.cisco.com/site/cisco-instant-connect/downloads/
WexbEx Teams Python Example
This example pulls from the GitHub page https://github.com/CiscoDevNet/webexteamssdk
Some things you will note from this SDK that is common to most SDKs:
- The SDK needs a Webex Teams “token” to make API calls, which can either be set with a WEBEX_TEAMS_ACCESS_TOKEN environment variable or by putting the access_token argument into the function of the API Call so it is passed into the function
- The SDK provides error reporting with the ApiError exception shown in the Python script right in the first line of the script itself
- The SDK allows access to specific parts of the call of the return body, for example “me.emails” will narrow down the return output to only “email” JSON data in the response
That will wrap up a quick review of SDKs, but you will need to know them for exam day!
I tried and tried to figure out how to put together a conclusive look at SDKs for different Cisco Platforms from the section of the DEVASC blueprint, but as with most of the Platform Specific stuff, I think this will come down to not reading it here but going to Cisco’s Developer site and playing with these Sandboxes to understand the Platforms / Reading Documentation to understand the workflow / dataflow for exam day.
Once I get through this course and can open it up for some review and labbing I’ll try to put together as much labbing output and demo’s I can, but for this test I don’t think that not labbing pretty extensively will be an option (and its becoming clearer how important Python is).
That being said, until next time!!!
The DEVNET GRIND! 