Up to this point, you've effectively utilized tools like SoapUI, explored the Webex documentation, and completed some basic Python examples to interact with and understand some of the most common Cisco collaboration APIs. The final goal of this lab is to create a web portal that allows administrators to perform business functions using a simple interface. As a web developer responsible for building this portal, you shouldn't have to get bogged down in the details of SOAP, REST, and the complexities of various APIs. For this purpose, you need to build a layer that hides these complexities.
Modern web development usually involves two groups of developers: front-end developers and back-end developers. Front-end developers typically focus on the user interface (UI), including HTML, CSS, and Javascript code that runs in the browser. Back-end developers, on the other hand, focus on the code running on the web server, managing the business logic when a user interacts with the UI. In this lab, you will play the role of the back-end developer, building the framework that allows the web UI to request data for display and to invoke requests for specific actions, such as adding a new Phone to UCM or enabling a user for calling features in Webex.
In the upcoming sections, you will use the Python programming language to extend a web server application to add support for Cisco UC SOAP and REST-based APIs. Essentially, you aim to create a web server capable of generating requests similar to what you performed using Python in previous sections. Many modern websites use an API-based approach to development, where the front-end invokes a REST API provided by the back-end. In simple terms, when a user on a web page performs an action, such as pressing a button or submitting some data, the front-end Javascript code makes a REST API call to the back-end with the information that was submitted. The same is true if the front-end needs to retrieve information, for example, getting the list of phones associated with a user. The front-end would make an API call asking for the list, and the back-end would handle invoking whatever API calls are needed to retrieve the data. Typically, the front-end API is much simpler than the true API being used to communicate with the product and provides just the fields and information needed by the front-end. For example, when adding a phone, the user may only need to enter the MAC address, description, and perhaps class of service for the phone. This information is provided to the back-end, and that request is used to construct the full API call needed to add a Phone to UCM.
This lab is not intended to be a class on website development. Therefore, a significant portion of the front-end code has been completed for you, and parts of the back-end as well. The lab structure allows you to focus on the actual work of programmatically interacting with the various collaboration APIs. The framework for the front-end API has already been created for you. You will be implementing the actions taken when these front-end API calls are made. For example, when the front-end wants the list of active services or some specific performance counters, you will write the code to retrieve those counters and pass them back to the front-end code running in the web browser. The functions that you will implement in Python are not intended to be a one-to-one match with what the API exposes. The goal is to build functions that make it easy for a front-end web developer to invoke business functions, such as adding/removing user phones, provisioning users in Webex, or sending Webex notifications with minimal effort. For example, sending a notification to a Webex space requires values like the RoomID. When implementing a "send notification" function, the back-end can allow the user to just enter the name of the space and handle figuring out the RoomID and other API parameters needed to send the notification.
The web server you will develop this portal with will be a Flask application. Flask is a microframework written in Python that allows you to create a web server. It is lightweight and very extensible. One of the extensions that we have provided for you in this lab is called the Flask-RESTX extension. This extension makes it easy to create a REST API of your own that will be used by the front-end code running in the web browser, similar to the capabilities in the Webex API documentation. We will call this API the front-end API (which runs on the back-end server).
We have already defined the API endpoints you will be creating. We have also added documentation for the API that you will implement. This combination of the RESTX extension and the documentation in the code allows you to invoke an interface called the >SwaggerUI. These are web pages that are automatically created for you which allow you to easily test your newly created API from a web browser, similar to the way you used the Webex API documentation pages to test REST APIs. The built-in SwaggerUI interface simply gives you an easy web interface to test the front-end API and allows you to make sure it is working without having to write any of the front-end code. Basically you want to make sure the API works before you hand it over to the front-end developer to develop the GUI. As you add more code and documentation to the code, the SwaggerUI picks up those changes and generates new web pages to test with.
Once you have finished implementing the front-end API on the back-end server, you will explore how the front-end "Provisioning Portal" web page makes use of the API and invokes the Python code you have written to give you a good idea of what you could build using these APIs.
One important point to note is that in this lab, the API you are implementing does not require any form of authentication. In a production environment, you would want to create a user login mechanism and then use that to authenticate the API calls from the front-end to the back-end. This is outside the scope of this lab, so the portal you build will not authenticate any of the API calls.
.
Doing so launches the web server with output going to a
terminal window at the bottom. 
* Running on http://10.0.106.40:5000/ (Press CTRL+C to quit)
Your web portal is active! It doesn't do much yet, but that will soon follow. Let's get started with the CUCM SOAP API functions.