Hook (1-2 sentences): Domo's APIs are inconsistent — the same concept might be id, page_id, or database_id depending on which endpoint you hit. Python classes fix this by giving you a single, predictable interface regardless of what the raw API returns.
Why It Matters (2-4 sentences): Without a class layer, every script you write has to re-learn the API's quirks — field name variations, authentication plumbing, and repeated boilerplate for common operations like enabling PDPs or triggering dataset execution. That means bugs multiply as scripts diverge, and onboarding anyone else to your codebase becomes painful. A well-designed class hierarchy means your teammates always know that DomoPage.id is id, full stop — and that any instance already knows how to authenticate itself.
What You'll Learn
- Build a
DomoJupyterContentclass that normalizes a single piece of Jupyter content with consistent attributes - Design a
DomoJupytermanager class that operates across all content objects (bulk operations, mapping, etc.) - Understand the separation between individual object classes and collection manager classes
- Pass an auth object into class methods so authentication is handled once, not per-call
- Apply this pattern to any Domo API resource — datasets, pages, cards — not just Jupyter
Class Design Patterns for Domo API Wrappers
The core insight here is the two-layer class model. DomoJupyterContent represents a single piece of content and carries attributes like name, folder, last_modified, file_type, and content. This class is responsible for operations on that one object. DomoJupyter sits above it — it's a manager class that handles collection-level concerns: listing all content, mapping over items to apply bulk operations, or filtering by type.
This mirrors a pattern you'll see in well-designed SDKs: don't mix resource-level and collection-level concerns in the same class.
Authentication gets handled by passing a fully-configured auth object into each method rather than hardcoding credentials or re-implementing token logic. The route method just calls into the auth class — it doesn't need to know whether you're using full auth, OAuth, or a service account. That separation is what made the earlier update_jupyter_file route so clean: one function signature, zero auth boilerplate in the business logic.
The practical payoff: when Domo changes a field name in a future API version, you update the class constructor in one place. Every script that uses DomoJupyterContent stays untouched. That's the consistency dividend classes pay out over time — and it's why building this layer early, even when a single script feels simpler, is the right call.
