Requirements

Functional

• Wrap the Webex Teams API endpoints in Python-native functions; the functions must accept all required and optional API parameters as inputs and return the response objects as Python-native objects.
• The library must provide Python-native data models for all documented API data models.
• An SDK user must be able to create a connection object providing their authentication and session parameters at initialization.
• Wrapped API endpoints must be exposed and hierarchically organized underneath the connection object.
• The library must raise Python-native exceptions for all API errors.
• The library must abstract and transparently handle API mechanics like pagination.
• The library must provide support for automatic API rate-limit handling; users should be able to disable this feature.
• Users must be able to install the library via Python's PIP package manager (pip install ___).
• Users must have the ability to install pre-release versions.

Non-Functional

In priority order, the following non-functional requirements represent goals and guiding principles for the library.

Security

• The library code should not expose confidential information (e.g., access tokens, Personally Identifiable Information (PII)) through logging, exceptions, or console output. A user's code may choose to do so, but the library should not.

Usability

• The library's structure and codebase should facilitate IDE autocompletion.
• The library should provide reasonable and overridable defaults for library configurations and function parameters. The goal is to reduce required user input to that which is essentially necessary (information that the library cannot obtain from any place other than the user).
• Every user-facing function should have a descriptive docstring that documents the function's parameters and expected behavior.
• The library should provide Quick Start documentation that walks the user through initial setup, use, standard operations, and essential features.
• The library should provide complete library-API documentation with full coverage for all exposed classes, methods, and parameters. Ideally, these should be auto-generated from the source code.

Extensibility

• The library should provide a mechanism to support user-provided data model classes. In other words, the library's API functions should be configurable to return objects generated from user-supplied classes.
• Provided data model classes should be extensible through sub-classing and patching.

Maintainability

• API wrapper functions should provide initial support for new API parameters without requiring a library code update.
• Provided data models should provide initial support for new object attributes and missing/deleted attributes without requiring a library code update.
• The codebase should leverage third-party libraries that provide common technical capabilities, and community developers should keep dependencies to an essential minimum.

Testability

• The library's test suite should include unit tests for all functions and methods.
• The library's test suite should include live integrations tests that execute against the production Webex APIs.

Portability

• The codebase and third-party dependencies should be pure-Python code (no platform-dependent C/C++ extensions).
• The library should install and function on any system that provides a supported Python runtime environment.

Transparency

• Library functions should generate sufficient log messages to inform the user what operations and actions the library is executing on their behalf.
• High-level data objects and exceptions should provide access to the low-level HTTP request and response data structures that the library used to construct the high-level objects.

Responsiveness

• All library operations should complete or fail (gracefully) within established time limits.
• Operation timeouts should be configurable and come preconfigured with reasonable defaults.